Subject: TSA draft V7.0

From: Michael Zolotarev <[email-masked]>
Date: Fri, 28 Apr 2000 11:35:05 +1000

Denis,
 
Something I've just noticed in the draft, which skipped my attention before:
 
The TSA draft defines how the AIA extension can be used in the TSA
certificate. 
***
A TSA's certificate MAY contain an Authority Information Access extension
[RFC2459] in order to convey the method of contacting the TSA. The
accessMethod field in this extension MUST contain the OID
id-ad-timestamping:
***
 
The definition actually contradicts to the 2459 profile which says:
 
***
The authority information access extension indicates how to access CA
information and services FOR THE ISSUER OF THE CERTIFICATE in which the
extension appears. Information and services may include on-line validation
services and CA policy data. 
****

Note the "FOR THE ISSUER OF THE CERTIFICATE" bit.

The content of the AIA extension does not depend on who the subject is. It
only depends on what information access services the CA has to offer. In
other words, a CA would most probably use the same AIA for a TSA cert and
for any other entity's certificate it generates .

The only possible situation I can think of when the definition given by the
TSA draft makes a tiny bit of sense is for self-signed TSA certificates. If
this is the case, the AIA would be presenting a set of protocols that can be
used to obtain timestamps. But then it must be clearly stated by the
document that only self-signed TSA certs can have that information in the
AIA extension. Still, it contradicts to the spirit of the 2459, which
defines the AIA as providing information about how to access the
certificate-issuing authority, but not the services offered by the subject
of the certificate.

The current definition in the TSA draft goes back to the very early version
of the draft. Probably, it is just me who is wrong, and there is something I
simply do not understand. Would like my concerns to be explained.

BTW, an alternative and in my opinion a better way of specifying the set of
URIs to obtain timestamps would probably be defining a proprietary extension
in TSA certificates. TsaAccessDescription ::= SEQUENCE SIZE (1..MAX) OF
GeneralName. Non-critical, with the id-ad-timestamping OID.

Best regards

M

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 28 Apr 2000 10:14:20 -0400

Hi Michael,

My interpretation is more along the following lines.  If a CA explicitly
puts an extension in a certificate designating the subject to be a TSA then,
in some sense at least, the time stamp authority function becomes a CA
service.  Thus, I see no conflict with such use of the AIA extension.

On the other hand, if a time stamper independently sets itself up as a TSA,
without any explicit "endorsement" from a CA, then this time stamp authority
function is not a CA service.  EEs will need to discover in some other way
that this is a TSA and will need to install the TSA public key in a secure
(out-of-band) fashion, independent of any contact with any CA.  Use of AIA
in this instance would indeed be contrary to the spirit of RFC 2459, but
that's not a problem since this instance is defined by the assumption that
AIA is not used.

So, I think the text is fine as-is, but I'd be interested in other
opinions/interpretations on this.

Carlisle.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Sent: 	Thursday, April 27, 2000 9:35 PM
> To: 	[email-masked]
> Cc: 	PKIX mailing group
> Subject: 	TSA draft V7.0
> 
> Denis,
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 28 Apr 2000 17:08:01 +0200 (MET DST)

> opinions/interpretations on this.

I would like to know how the two type of access information that had
been in earlier drafts of X.509 were lost. 

The AIA tells you something about the issuer, and there were two others
that concerned End entity information access and CA information access.
(both seem to be identical with the only difference that the subject
is a EE or a CA.) 

I had asked this question a year ago I guess.

---

From: [email-masked]
Date: Fri, 28 Apr 2000 20:22:21 -0400

Carlisle Adams <[email-masked]> on 04/28/2000 10:14:20 AM

To:   [email-masked], "'Michael Zolotarev'"
      <[email-masked]>
cc:   PKIX mailing group <[email-masked]>
Subject:  RE: TSA draft V7.0

Hi Michael,

My interpretation is more along the following lines.  If a CA explicitly
puts an extension in a certificate designating the subject to be a TSA
then, in some sense at least, the time stamp authority function becomes a
CA service.  Thus, I see no conflict with such use of the AIA extension.

[Tom Gindin] I have a hard time with the idea that a service becomes a CA
service in any meaningful sense simply by having the CA issue a certificate
containing an ExtendedKeyUsage value.  A CA issuing a server certificate is
not vouching that the service will be properly performed, much less that it
will be performed on the CA's behalf.  How much verification of the
features of a service by the CA occurs  when an operator gets a server
certificate for a Web or LDAP server and asks for Extended Key Usage
id-kp-serverAuth?  So how much more is required for id-kp-timeStamping,
which is the standard way in which the CA designates the subject as a TSA?
(snip)

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 1 May 2000 10:55:42 +1000

Carlisle,

Let me explain my point once again:

The 2459 defines the AIA extension as containing information about the
ISSUER of a certificate. Be it a TSA, or any other certificate. Therefore,
the AIA extension in a TSA certificate is expected to provide details about
the CA that issued that certificate, but not about the TSA itself.

Assuming that a CA generates a certificate for TSA so that the AIA somehow
contains the TSA's details - how would you know if the extension really
contains information about issuing CA, or the TSA? The freedom if
interpretation would be dangerously confusing.

This is why it would be only reasonable to have the AIA in self-signed TSA
certificates.

Regards
Michael

> -----Original Message-----
> From: Carlisle Adams [mailto:[email-masked]]
> Sent: Saturday, April 29, 2000 12:14 AM
> To: [email-masked]; 'Michael Zolotarev'
> Cc: PKIX mailing group
> > The only possible situation I can think of when the 
> definition given by
> > the
> > TSA draft makes a tiny bit of sense is for self-signed TSA 
> certificates.
> > If
> > this is the case, the AIA would be presenting a set of 
> protocols that can
> > be
> > of the draft. Probably, it is just me who is wrong, and 
> there is something
> > I
> > BTW, an alternative and in my opinion a better way of 
> specifying the set
> > of

---

From: Michael Zolotarev <[email-masked]>
Date: Mon, 1 May 2000 11:14:59 +1000

I agree that it would be extremely difficult for a CA to evaluate a TSA's
practices before granting it a certificate with id-timestamping. It would be
even more difficult for me, as a client, to trust that assessment.

That is why is seems reasonable to expect that TSA would use self-signed
certificates, taking full responsibility over its practices and operations.

However, I reckon that this is largely outside of the scope of the
timestamping draft, really.

Regards
Michael

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, April 29, 2000 10:22 AM
> To: Carlisle Adams
> Cc: [email-masked]; 'Michael Zolotarev'; PKIX mailing group

From: Michael Zolotarev <[email-masked]>
To: [email-masked], Carlisle Adams <[email-masked]>
Cc: [email-masked], PKIX mailing group <[email-masked]>
Subject: RE: TSA draft V7.0
Date: Mon, 1 May 2000 11:14:59 +1000 

I agree that it would be extremely difficult for a CA to evaluate a TSA's
practices before granting it a certificate with id-timestamping. It would be
even more difficult for me, as a client, to trust that assessment.

That is why is seems reasonable to expect that TSA would use self-signed
certificates, taking full responsibility over its practices and operations.

However, I reckon that this is largely outside of the scope of the
timestamping draft, really.

Regards
Michael

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, April 29, 2000 10:22 AM
> To: Carlisle Adams
> Cc: [email-masked]; 'Michael Zolotarev'; PKIX mailing group

From: Michael Zolotarev <[email-masked]>
To: Carlisle Adams <[email-masked]>, [email-masked]
Cc: PKIX mailing group <[email-masked]>
Subject: RE: TSA draft V7.0
Date: Mon, 1 May 2000 10:55:42 +1000 

Carlisle,

Regards
Michael

> > GeneralName. Non-critical, with the id-ad-timestamping OID.

From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: PKIX mailing group <[email-masked]>
Subject: RE: TSA draft V7. OIDs.
Date: Mon, 1 May 2000 10:34:55 +1000 

> > C1. The draft uses both id-ad-timeStamping and 
> id-pkix-ad-timestamping OIDs.
> > I'd prefer "pkix" to be preserved as part of the name.
> 
> They come from two different arcs (SMIME and PKIX).
> 

Denis, I've put the OIDs together below. To me they are identical :)

id-pkix-ad-timestamping  OBJECT IDENTIFIER ::= {id-pkix-ad 3}
id-pkix-ad               OBJECT IDENTIFIER ::= {id-pkix 48}
id-pkix                  OBJECT IDENTIFIER ::= {iso(1) 
                         identified-organization(3) dod(6) 
                         internet(1) security(5) mechanisms(5) pkix(7)}

id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1) 
                      identified-organization(3) dod(6) 
                      internet(1) security(5) mechanisms(5) pkix(7) 
                      ad (48) timestamping (3)}

M 

From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>, PKIX mailing group <[email-masked]>
Subject: RE: TSA draft V7. certReq field.
Date: Mon, 1 May 2000 10:29:27 +1000 

Ok.

Except is probably sounds a little better to say: "IN THIS CASE that field
may also
contain other certificates."

Michael

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, April 28, 2000 8:39 PM
> To: Michael Zolotarev; PKIX mailing group
> Subject: Re: TSA draft V7
> 
> 
> Michael,
> 
> On the gfirst point I answered to quickly.
> 
> The idea is to return the relevant certificate in the certificates
> field from the SignedData structure.
> 
> Here after is the complete fix:
> 
> If the certReq field is present and set to true, the TSA's public
> key certificate that is referenced by the ESSCertID attribute in the 
> response must be provided by the TSA in the certificates field from 
> the SignedData structure in that response. That field may also
> contain 
> other certificates.
> 
> If the certReq field is missing, or if the certReq field is present
> and set to false then the certificates field from the SignedData 
> structure must not be present in the response.
> 
> Denis
> 
>  
> > > A few more remarks:
> > 
> > > The draft says:
> > 
> > > "If the certReq field is present and set to true, the 
> TSA's public key
> > > certificate that is referenced by the ESSCertID attribute 
> must be provided
> > > by the TSA in the Certificate Values attribute and 
> incorporated in the
> > > response. The certificate Values attribute may also contain other
> > > certificates.
> > > If the certReq field is missing, or if the certReq field 
> is present and set
> > > to false then no Certificate Values attribute shall be present."
> > 
> > > Q1. "Certificate Values attribute". What is it? Was it 
> meant to be the
> > > signedData::Certificates field?
> > 
> > You are right. It is "Signing Certificate" instead of "Certificate
> > Values". Good catch.
> > 
> > > Q2. If the certReq field is missing in the request, 
> should it be up to the
> > > TSA to decide whether to include the cert of not?
> > 
> > The text is pretty explicit on this. The TSA does not decide : No
> > certificate sahll be present.
> > 
> > > Q3. somehow it seems more reasonable to default the 
> certReq to TRUE. This
> > > way TSA would be well-behaving with no extra efforts.
> > 
> > The answer should be as short as possible in the general case. If
> > you really want the certificate back, then you have to ask for it.
> > 
> > > General comments:
> > >
> > > C1. The draft uses both id-ad-timeStamping and 
> id-pkix-ad-timestamping OIDs.
> > > I'd prefer "pkix" to be preserved as part of the name.
> > 
> > They come from two different arcs (SMIME and PKIX).
> > 
> > > C2. PKIXTSP is defined but never referenced.
> > 
> > The name is there so that *other* ASN 1 modules may reference it and
> > use what is exported.
> > 
> > Denis
> > 
> > >
> > > Regards
> > >
> > > M
> 

Date: Sun, 30 Apr 2000 18:29:59 +0300
From: Efrat Prag <[email-masked]>
To: [email-masked]
Subject: enrollment protocols

Hi,

I am looking into the subject of certificate enrollment protocols. From
what I've heard CEP is the most common one. However I haven't been able
to locate a draft/rfc of the protocol. I did find a draft on SCEP with
no reference to CEP. Are the two protocols related?
Can anyone point me to such a document?

Thanks,
Efrat

From: [email-masked]
To: Carlisle Adams <[email-masked]>
cc: [email-masked], "'Michael Zolotarev'" <[email-masked]>, PKIX mailing group <[email-masked]>
Date: Fri, 28 Apr 2000 20:22:21 -0400
Subject: RE: TSA draft V7.0

Hi Michael,

From: Peter Sylvester <[email-masked]>
Date: Fri, 28 Apr 2000 17:08:01 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: TSA draft V7.0
Cc: [email-masked]

From: Peter Sylvester <[email-masked]>
Date: Fri, 28 Apr 2000 17:03:10 +0200 (MET DST)
To: [email-masked]
Subject: Re: time-stamp-draft-7
Cc: [email-masked]

> 
> I suggest changing the tagging to:
> 
> TSTInfo ::= SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
> 

Another way is to change the order of some precding element. Idoubt that
one of the choices of GeneralName will ever become a sequence directly.

TSTInfo ::= SEQUENCE  {
     version                      Integer  { v1(1) },
     policy                       PolicyInformation,
     messageImprint               MessageImprint,
       -- MUST have the same value as the similar field in 
       -- TimeStampReq
     genTime                      GeneralizedTime,
     accuracy                     Accuracy             OPTIONAL,
     serialNumber                 Integer,
     nonce                        Integer              OPTIONAL,
       -- MUST be present if the similar field was present 
       -- in TimeStampReq. In that case it must have the same value.
     tsa                          GeneralName          OPTIONAL,

     extensions                   Extensions       OPTIONAL
}

And in order to follow the 'MIMIMAL' tagging I suggest the following

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(1) },
     messageImprint               MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy                PolicyInformation      OPTIONAL,
     nonce                    Integer                OPTIONAL,
     certReq                  BOOLEAN                DEFAULT FALSE,
     extensions               [0] IMPLICIT Extensions OPTIONAL
}

in order to get minimal tagging and to avoid any possible conflict
when some interpretes it a EXPLICIT.  

Date: Fri, 28 Apr 2000 17:00:20 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: [email-masked]
CC: [email-masked]
Subject: Re: time-stamp-draft-7

It would work, but who knows in which way GeneralName will be changed in
future. To add one more tag seems to be cleaner. Another "dirty" change would
be to tag Extensions with [1]. Since In GeneralName the tag [1] is used for a
primitive type (IA5String) the encoding differs from the encoding of the
Extensions tag. I'd rather add another tag.

Jörg
--
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

[email-masked] schrieb:
> 
>      It is equally safe to give extensions a high tag and leave GeneralName
> untagged, e.g. TSTInfo ::= SEQUENCE
> {         [...]
>       tsa                   GeneralName          OPTIONAL,
>       extensions            [30] IMPLICIT Extensions OPTIONAL
> }
> 
>      Wouldn't this be better than throwing in extra tags?  Tag numbers
> above 30 should be avoided whenever possible, of course, because they are
> multi-byte tags.  Of course, since Accuracy is an optional sequence,
> leaving extensions untagged doesn't work.

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: What do you put in crlEntryDetails?
Date: Fri, 28 Apr 2000 15:25:39 +0100

The RevDetails structure has a field called "crlEntryDetails" which takes
certificate extensions.  I have written code to access this field but for
the world of me I cannot think what somebody would use it for.  Can anybody
give me an examples of certificate extensions that one might stick in
crlEntryDetails?

Cheers,

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Carlisle Adams <[email-masked]>
To: [email-masked], "'Michael Zolotarev'" <[email-masked]>
Cc: PKIX mailing group <[email-masked]>
Subject: RE: TSA draft V7.0
Date: Fri, 28 Apr 2000 10:14:20 -0400

Hi Michael,

Carlisle.

From: [email-masked]
To: Denis Pinkas <[email-masked]>
cc: Joerg Seidel <[email-masked]>, [email-masked]
Date: Fri, 28 Apr 2000 09:50:28 -0400
Subject: Re: time-stamp-draft-7

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

     It is equally safe to give extensions a high tag and leave General=
Name
untagged, e.g. TSTInfo ::=3D SEQUENCE
{         [...]
      tsa                   GeneralName          OPTIONAL,
      extensions            [30] IMPLICIT Extensions OPTIONAL
}

     Wouldn't this be better than throwing in extra tags?  Tag numbers
above 30 should be avoided whenever possible, of course, because they a=
re
multi-byte tags.  Of course, since Accuracy is an optional sequence,
leaving extensions untagged doesn't work.

          Tom Gindin

Denis Pinkas <[email-masked]> on 04/28/2000 06:10:29 AM

To:   Joerg Seidel <[email-masked]>
cc:   [email-masked]
Subject:  Re: time-stamp-draft-7

Joerg,

Thanks for your careful writing. We came form a maximum tagging
version (which was safe) to a minimum one. It is hard to do minimal
tagging by thinking to all the various combinations.

You are right. Thanks for providing a change proposal.

Denis

> Denis,
>
> maybe the TSTInfo structure has some inconvenience because of the mis=
sing
tags
> now:
>
> time-stamp-draft-7: IMPLIZIT tagging
>
> TSTInfo ::=3D SEQUENCE  {
>         [...]
>      tsa                          GeneralName          OPTIONAL,
>      extensions                   [0] Extensions       OPTIONAL
> }
>
> X.509 IMPLIZIT: Tagging:
>
>       GeneralName ::=3D CHOICE {
>            otherName                       [0]     OtherName,
>            rfc822Name                      [1]     IA5String,
>            dNSName                         [2]     IA5String,
>            x400Address                     [3]     ORAddress,
>            directoryName                   [4]     Name,
>            ediPartyName                    [5]     EDIPartyName,
>            uniformResourceIdentifier       [6]     IA5String,
>            iPAddress                       [7]     OCTET STRING,
>            registeredID                    [8]     OBJECT IDENTIFIER}=

>
>       OtherName ::=3D SEQUENCE {
>            type-id    OBJECT IDENTIFIER,
>            value      [0] EXPLICIT ANY DEFINED BY type-id }
>
>    Extensions  ::=3D  SEQUENCE SIZE (1..MAX) OF Extension
>
> The parser can't ditinguish between the "GeneralName" field and "[0]
> Extensions" in case that the GeneralName choice is "[0] OtherName". S=
ince
both
> OtherName and Extensions are sequences the tag will be encoded
identically and
> can't be used to distinguish the two optional entries. They could onl=
y
> distinguished by checking the tag of the content of the sequence. Tha=
t
isn't
> very convinient for implementations.
>
> I suggest changing the tagging to:
>
> TSTInfo ::=3D SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
>
> Jorg
>
> --
> timeproof                               phone  +49-40-76629-1911
> Development                             fax    +49-40-76629-551
> Harburger Schlo=DFstra=DFe 6-12             mailto:[email-masked]=
e
> D-21079 Hamburg                         http://www.timeproof.de

=

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk
Content-type: application/X-Lotus-Encap2; 
	name="encap2.ond"
Content-transfer-encoding: base64

////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk--

Date: Fri, 28 Apr 2000 12:39:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Zolotarev <[email-masked]>, PKIX mailing group <[email-masked]>
Subject: Re: TSA draft V7

Michael,

On the gfirst point I answered to quickly.

The idea is to return the relevant certificate in the certificates
field from the SignedData structure.

Here after is the complete fix:

If the certReq field is present and set to true, the TSA's public
key certificate that is referenced by the ESSCertID attribute in the 
response must be provided by the TSA in the certificates field from 
the SignedData structure in that response. That field may also
contain 
other certificates.

If the certReq field is missing, or if the certReq field is present
and set to false then the certificates field from the SignedData 
structure must not be present in the response.

Denis

> > A few more remarks:
> 
> > The draft says:
> 
> > "If the certReq field is present and set to true, the TSA's public key
> > certificate that is referenced by the ESSCertID attribute must be provided
> > by the TSA in the Certificate Values attribute and incorporated in the
> > response. The certificate Values attribute may also contain other
> > certificates.
> > If the certReq field is missing, or if the certReq field is present and set
> > to false then no Certificate Values attribute shall be present."
> 
> > Q1. "Certificate Values attribute". What is it? Was it meant to be the
> > signedData::Certificates field?
> 
> You are right. It is "Signing Certificate" instead of "Certificate
> Values". Good catch.
> 
> > Q2. If the certReq field is missing in the request, should it be up to the
> > TSA to decide whether to include the cert of not?
> 
> The text is pretty explicit on this. The TSA does not decide : No
> certificate sahll be present.
> 
> > Q3. somehow it seems more reasonable to default the certReq to TRUE. This
> > way TSA would be well-behaving with no extra efforts.
> 
> The answer should be as short as possible in the general case. If
> you really want the certificate back, then you have to ask for it.
> 
> > General comments:
> >
> > C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
> > I'd prefer "pkix" to be preserved as part of the name.
> 
> They come from two different arcs (SMIME and PKIX).
> 
> > C2. PKIXTSP is defined but never referenced.
> 
> The name is there so that *other* ASN 1 modules may reference it and
> use what is exported.
> 
> Denis
> 
> >
> > Regards
> >
> > M

Date: Fri, 28 Apr 2000 12:10:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Joerg Seidel <[email-masked]>
CC: [email-masked]
Subject: Re: time-stamp-draft-7

Joerg,

Thanks for your careful writing. We came form a maximum tagging
version (which was safe) to a minimum one. It is hard to do minimal
tagging by thinking to all the various combinations.

You are right. Thanks for providing a change proposal.

Denis
 
> Denis,
> 
> maybe the TSTInfo structure has some inconvenience because of the missing tags
> now:
> 
> time-stamp-draft-7: IMPLIZIT tagging
> 
> TSTInfo ::= SEQUENCE  {
>         [...]
>      tsa                          GeneralName          OPTIONAL,
>      extensions                   [0] Extensions       OPTIONAL
> }
> 
> X.509 IMPLIZIT: Tagging:
> 
>       GeneralName ::= CHOICE {
>            otherName                       [0]     OtherName,
>            rfc822Name                      [1]     IA5String,
>            dNSName                         [2]     IA5String,
>            x400Address                     [3]     ORAddress,
>            directoryName                   [4]     Name,
>            ediPartyName                    [5]     EDIPartyName,
>            uniformResourceIdentifier       [6]     IA5String,
>            iPAddress                       [7]     OCTET STRING,
>            registeredID                    [8]     OBJECT IDENTIFIER}
> 
>       OtherName ::= SEQUENCE {
>            type-id    OBJECT IDENTIFIER,
>            value      [0] EXPLICIT ANY DEFINED BY type-id }
> 
>    Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
> 
> The parser can't ditinguish between the "GeneralName" field and "[0]
> Extensions" in case that the GeneralName choice is "[0] OtherName". Since both
> OtherName and Extensions are sequences the tag will be encoded identically and
> can't be used to distinguish the two optional entries. They could only
> distinguished by checking the tag of the content of the sequence. That isn't
> very convinient for implementations.
> 
> I suggest changing the tagging to:
> 
> TSTInfo ::= SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
> 
> Jorg
> 
> --
> timeproof                               phone  +49-40-76629-1911
> Development                             fax    +49-40-76629-551
> Harburger Schloßstraße 6-12             mailto:[email-masked]
> D-21079 Hamburg                         http://www.timeproof.de

Date: Fri, 28 Apr 2000 12:06:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Zolotarev <[email-masked]>
CC: PKIX mailing group <[email-masked]>
Subject: Re: TSA draft V7

> A few more remarks:
 
> The draft says:

> "If the certReq field is present and set to true, the TSA's public key
> certificate that is referenced by the ESSCertID attribute must be provided
> by the TSA in the Certificate Values attribute and incorporated in the
> response. The certificate Values attribute may also contain other
> certificates.
> If the certReq field is missing, or if the certReq field is present and set
> to false then no Certificate Values attribute shall be present."
 
> Q1. "Certificate Values attribute". What is it? Was it meant to be the
> signedData::Certificates field?

You are right. It is "Signing Certificate" instead of "Certificate
Values". Good catch.

> Q2. If the certReq field is missing in the request, should it be up to the
> TSA to decide whether to include the cert of not?

The text is pretty explicit on this. The TSA does not decide : No
certificate sahll be present.
 
> Q3. somehow it seems more reasonable to default the certReq to TRUE. This
> way TSA would be well-behaving with no extra efforts.

The answer should be as short as possible in the general case. If
you really want the certificate back, then you have to ask for it.

> General comments:
> 
> C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
> I'd prefer "pkix" to be preserved as part of the name.

They come from two different arcs (SMIME and PKIX).

> C2. PKIXTSP is defined but never referenced.

The name is there so that *other* ASN 1 modules may reference it and
use what is exported.

Denis

> M

Date: Fri, 28 Apr 2000 10:34:38 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: Permanent identifiers in QC

Peter,

(snip)
 
> Anyway: If you change your name, you might WANT the consequence of
> loosing the relationship automatically detectable by an RP.

Yes, since Permanent identifiers are OPTIONAL.

Denis

Date: Fri, 28 Apr 2000 09:19:20 +0200
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: [email-masked]
Subject: time-stamp-draft-7

Denis,

maybe the TSTInfo structure has some inconvenience because of the missing tags
now:

time-stamp-draft-7: IMPLIZIT tagging

TSTInfo ::= SEQUENCE  {
	[...]
     tsa                          GeneralName          OPTIONAL,
     extensions                   [0] Extensions       OPTIONAL
}

X.509 IMPLIZIT: Tagging:

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

The parser can't ditinguish between the "GeneralName" field and "[0]
Extensions" in case that the GeneralName choice is "[0] OtherName". Since both
OtherName and Extensions are sequences the tag will be encoded identically and
can't be used to distinguish the two optional entries. They could only
distinguished by checking the tag of the content of the sequence. That isn't
very convinient for implementations.

I suggest changing the tagging to:

TSTInfo ::= SEQUENCE  {
    [...]
     tsa                          [0] GeneralName      OPTIONAL,
     extensions                   [1] Extensions       OPTIONAL
}

Jorg

--
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

From: Michael Zolotarev <[email-masked]>
To: PKIX mailing group <[email-masked]>
Cc: [email-masked]
Subject: TSA draft V7
Date: Fri, 28 Apr 2000 13:02:14 +1000

A few more remarks:
 
The draft says:
"If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID attribute must be provided
by the TSA in the Certificate Values attribute and incorporated in the
response. The certificate Values attribute may also contain other
certificates.
If the certReq field is missing, or if the certReq field is present and set
to false then no Certificate Values attribute shall be present."
 
Q1. "Certificate Values attribute". What is it? Was it meant to be the
signedData::Certificates field?
 
Q2. If the certReq field is missing in the request, should it be up to the
TSA to decide whether to include the cert of not?
 
Q3. somehow it seems more reasonable to default the certReq to TRUE. This
way TSA would be well-behaving with no extra efforts.

General comments:

C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
I'd prefer "pkix" to be preserved as part of the name.

C2. PKIXTSP is defined but never referenced.

Regards

M

From: Michael Zolotarev <[email-masked]>
To: [email-masked]
Cc: PKIX mailing group <[email-masked]>
Subject: TSA draft V7.0
Date: Fri, 28 Apr 2000 11:35:05 +1000

Denis,

 
 
***

Best regards

M

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 27 Apr 2000 17:02:33 -0400

Hi Peter,

> ----------
> From: 	Peter Williams[SMTP:[email-masked]]
> Sent: 	Thursday, April 20, 2000 11:01 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> We have seemingly cleared up or determined
> three technical points from the discussion. Do
> say if any description below is not
> correct - in your view.
> 
> (1) a CMP responder does not need to send any
> particular cert path to the subscriber, when
> returning the EE cert for EE acceptance. The UA
> should not assume presence of any particular
> certs, including the CA cert or any superior
> certs in the domain's trust network, in the 
> message field in discussion. Futhermore, any
> certs that are sent are in bag order.
 
Agreed.

Note, however, the distinction between the caPubs field in the initRep
message (Section 3.3.2) and the extraCerts field in PKIMessage (Section
3.1).  The initializing EE must receive its trust anchor(s) in some reliable
way.  If this has not happened by some other (out-of-band) means, then the
caPubs field is a convenient and reasonable place to do this.  Certs found
here (in bag order) are intended to be directly trusted as root certificates
and need not be validated prior to acceptance of the newly-issued EE
cert(s).  This implies that they are valid at the moment of creation of this
response message.  It also implies that there is no certificate path here
(there's no reason I can think of to have every CA in a path be a trust
anchor for a given EE).

It is the extraCerts field (again in bag order) that may contain various
"helpful" certs, including (partial) paths.  Such certificates carry no
particular assurance of validity (even at the moment of creation of this
response message) and SHOULD, like all other non-root certificates, be
validated by the EE immediately prior to use.

> (2) According to CMP designers, the UA does not
> need to verify the signature of the 
> EE certificate upon initial receipt (which
> in many enrollment circumstances will constitute the
> moment of making an acceptance determination.) Such
> UA does not therefore need any certificate
> paths or CRLs ( or othe status source) at that 
> point in time.
 
Agreed.

The newly-issued certificate may be assumed to be "mechanically valid", by
which I mean that the path from this certificate to the relevant root
certificate is valid according to the mechanical processing rules.  By
accepting the certificate, the EE is telling the CA that the contents of the
newly-issued certificate are acceptable (i.e., validity period is fine;
contained policies are fine; etc., etc.).  The EE need not check signatures,
ARLs for any intermediate CA certs, etc..

> (3) CMP's CRL retrieval service is not meant
> to be a PKIX operational protocol. It is not
> clear if a conforming CMP implementation and CA
> will provide this facility.
 
Agreed.

It is "not clear" because the relevant CMP messages are OPTIONAL (i.e.,
they're not included in the set of messages specified as mandatory for
conformance in Section 4).  These messages, or the PKIX operational protocol
messages, or any other means may be used by the EE to retrieve revocation
information.

Carlisle.

P.S., Good summary of the discussion thus far -- thanks!

From: Peter Sylvester <[email-masked]>
Date: Thu, 27 Apr 2000 22:51:08 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Permanent identifiers in QC
Cc: [email-masked]

> 
>  Peter> ...
>  Peter> In most cultures, you don't change names *VERY* often.
> 
> In a fair number of cultures, somewhat less than half the people
> change their name at least once during their lifetime.

Let's say: Most persons once. (depending who choose the name
of the other partner and so on). 

> 
> Also, in some countries (the USA for example), quite apart from that
> general rule, you're pretty much free to change your name if you
> wish.  In fact, when immigrants are naturalized they are specifically
> told that this may be a good time to consider changing their name.

Right, if I ever try to become French I can also do that change my
name to Pierre Dubois or Roch Lasilve :-)

Anyway: If you change your name, you might WANT the consequence of
loosing the relationship automatically detectable by an RP.

It might be interesting to consider a certificate that contains
a subject with the newname and an alternatesubject with the old name
and this cert could be used to show it to some relying party in order
to establis a link.

Also, for pseudonyms, CA could create a cert, so that the subject CAN
use it to show ist REAL identity, for example. 

Date: Thu, 27 Apr 2000 19:26:01 +0100
From: Bruno Salgueiro <[email-masked]>
Organization: SIBS
To: [email-masked]
Subject: Re: Permanent identifiers in QC

Hi everyone.

  As I'm involved in the development of a PKI this topic interests me.
  I always thought that the main responsible for the attribution of a
cer-
tificate would be the Registration Authority. It is this entity which
will
verify an individual identity, allocate a DN from its namespace defined
by
the CA (or after the approval of the CA) and then deliver the
authorisation
tokens to retrieve the certificate. If you want, the CA can also be the
RA
but it is the role separation I'm interested in.

  But if you have n RAs for the same CA and if the CA doesn't know who
is
applying (it is trusting the RA to do so), how can we allocate an unique
identifier for each person? And if you could, how would you then issue
anonymous certificates? Remember that a certificate doesn't need to
assure
a name, might be a role, an account number, etc. So, sometimes it
doesn't
really matter the person itself, onle the proof of possesion of a token.
  Finally, I'm aware that attribute certificates are ideally used to
assure
a third party of an account number but as of today, if someone needs to
do
this, it will use regular certificates. And for account numbers, it
might
even be desirable not to associated them with a person when you're
buying
or presenting them as a ticket...

  I would really like to read some comments about this. Nevertheless,
and
no flames please, what the heck is QC???!??

Regards,

Paul Koning wrote:
> 
> >>>>> "Peter" == Peter Sylvester <[email-masked]> writes:
> 
>  >>  Would you explain how, when the name of that person changes ?
>  >>
>  >> > This type of control is something that typically will be
>  >> performed only in > case of problems, i.e. on rare occasions where
>  >> some efforts to investigate > change in names are a reasonable.
>  >>
>  >> It may be useful for day to day work.
> 
>  Peter> ...
>  Peter> In most cultures, you don't change names *VERY* often.
> 
> In a fair number of cultures, somewhat less than half the people
> change their name at least once during their lifetime.
> 
> Also, in some countries (the USA for example), quite apart from that
> general rule, you're pretty much free to change your name if you
> wish.  In fact, when immigrants are naturalized they are specifically
> told that this may be a good time to consider changing their name.
> 
>      paul

-- 
=======================================================
Bruno Salgueiro       (mailto:[email-masked])
                   
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

Esta mensagem foi assinada com certificado MULTIcert.
Para obter o certificado da Autoridade de Certificação
PILOTO MULTIcert dirija-se ao site
            http://www.sibs.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================

From: Paul Koning <[email-masked]>
Date: Thu, 27 Apr 2000 13:24:27 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Permanent identifiers in QC

>>>>> "Peter" == Peter Sylvester <[email-masked]> writes:

 >>  Would you explain how, when the name of that person changes ?
 >> 
 >> > This type of control is something that typically will be
 >> performed only in > case of problems, i.e. on rare occasions where
 >> some efforts to investigate > change in names are a reasonable.
 >> 
 >> It may be useful for day to day work.

 Peter> ...
 Peter> In most cultures, you don't change names *VERY* often.

In a fair number of cultures, somewhat less than half the people
change their name at least once during their lifetime.

Also, in some countries (the USA for example), quite apart from that
general rule, you're pretty much free to change your name if you
wish.  In fact, when immigrants are naturalized they are specifically
told that this may be a good time to consider changing their name.

     paul

From: Peter Sylvester <[email-masked]>
Date: Thu, 27 Apr 2000 19:12:25 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Permanent identifiers in QC
Cc: [email-masked]

> 
> Would you explain how, when the name of that person changes ?
> 
> > This type of control is something that typically will be performed only in
> > case of problems, i.e. on rare occasions where some efforts to investigate
> > change in names are a reasonable.
> 
> It may be useful for day to day work.

Big Brother is watching You.

The simple desire to create unique identifiers to trace down people
has not yet resulted in a society where all indiviuals get a 
bar code tatoo just after birth. 

Sorry, we are living a a world where people can have more than
one passport, they can change names, and on all kinds of
official documents you need the name changed.

In most cultures, you don't change names *VERY* often. And the benefit
of finding out that you have not given a free gift twice to the
same person in 1 out 100000 cases does not really convincing
compared with all possible negative impacts. 
Sometimes, if you marry twice, it might be desirable to loose some
tracability.

trying to declare something as PERMANENT does not help anyway, because
in this case, some people will get multiple permanent identifiers
anyway for some more or less obvious reasons.

Date: Thu, 27 Apr 2000 17:14:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stefan Santesson <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Permanent identifiers in QC

Stefan,

Comments in line;

> Denis
> Comment in-line;
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > Subject: Re: Permanent identifiers in QC
> >
> >
> >
> > > Folks, I've been sort of off-line the last days.
> >
> > > So as caching up with this thread I think we need to decide
> > the progress of
> > > this issue.
> >
> > > I would just want to add an observation regarding NR and
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and
> > ensure that these
> > > certificates identifies the same person EVEN if some parts
> > of the DN is not
> > > matching.
> >
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> >
> 
> For non-repudiation, it will be possible to determine that two different
> DN:s refer to the same person without the use of "permanent identifiers".

Would you explain how, when the name of that person changes ?

> This type of control is something that typically will be performed only in
> case of problems, i.e. on rare occasions where some efforts to investigate
> change in names are a reasonable.

It may be useful for day to day work.

Denis

> /Stefan

From: Stefan Santesson <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Permanent identifiers in QC
Date: Thu, 27 Apr 2000 16:58:44 +0200

Denis

Comment in-line;

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 26, 2000 10:27 AM
> To: Stefan Santesson
> Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> Subject: Re: Permanent identifiers in QC
> 
> 
>  
> > Folks, I've been sort of off-line the last days.
>  
> > So as caching up with this thread I think we need to decide 
> the progress of
> > this issue.
>  
> > I would just want to add an observation regarding NR and 
> Authentication.
> > The issue is NOT whether permanent identifiers are of value for
> > Authentication or NR. What IS an issue is whether it is 
> relevant for NR to
> > be able to compare 2 names in 2 different certificates and 
> ensure that these
> > certificates identifies the same person EVEN if some parts 
> of the DN is not
> > matching.
> 
> For non-repudiation, the permanent identifier may be used to link
> different transactions to the same individual, even when the subject
> name of the individual changes. So it is relevant.
> 

For non-repudiation, it will be possible to determine that two different
DN:s refer to the same person without the use of "permanent identifiers".

This type of control is something that typically will be performed only in
case of problems, i.e. on rare occasions where some efforts to investigate
change in names are a reasonable.

/Stefan

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt
Date: Thu, 27 Apr 2000 06:52:27 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-07.txt
	Pages		: 21
	Date		: 26-Apr-00
	
A time stamping service allows to prove that a datum existed before 
a particular time and can be used by a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]). This document describes the format of a request sent to a 
Time Stamping Authority (TSA) and of the response that is returned.
An example of how to prove that a digital signature was generated 
during the validity period of a public key certificate is given 
in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-07.txt

Internet-Drafts are also 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-time-stamp-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Wed, 26 Apr 2000 10:27:26 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stefan Santesson <[email-masked]>
CC: Russ Housley <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Permanent identifiers in QC

> Folks, I've been sort of off-line the last days.
 
> So as caching up with this thread I think we need to decide the progress of
> this issue.
 
> I would just want to add an observation regarding NR and Authentication.
> The issue is NOT whether permanent identifiers are of value for
> Authentication or NR. What IS an issue is whether it is relevant for NR to
> be able to compare 2 names in 2 different certificates and ensure that these
> certificates identifies the same person EVEN if some parts of the DN is not
> matching.

For non-repudiation, the permanent identifier may be used to link
different transactions to the same individual, even when the subject
name of the individual changes. So it is relevant.

> This particular aspect is only raised as a feature for access control (when
> an entity changes his certificate, or possesses several certificates with
> different DN). In the case of NR and legal signatures, the only issue is to
> establish the relation between a certificate and the individual key holder
> (regardless of other certificates). Here the current profile provides the
> necessary means.

No. See above.

> But....

Following the discussion on the serial Number and the Permanent
Identifier that took place on the PKIX mailing list and at the last
IETF meeting in Adelaïde, I am paying more and more attention to the
QC draft.

The document is defining the concept of "unmistakable identity". Now
that we have introduced the use of serialNumber, I wonder why such a
concept is still needed.

First, the wording "unmistakable identity" is not used in the
Directive, so this is the first reason why I wonder it is needed.

Second, let us recall, what RFC 2459 says:

   The subject field from a public key certificate identifies the 
   entity associated with the public key stored in the subject
public 
   key field.  The subject name may be carried in the subject field 
   and/or the subjectAltName extension.

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name
field.

The current specification (QC-03) mandates the use of the subject
field. In such a case, as defined *in RFC 2459*, the name is unique.
Moreover, it is unique not only at an instant of time, but during
the whole life of the CA. Note that ISO/ITU X.509 does not mandate
this and I guess this is where the problem comes from. The current
QC-03 document references *X.501* while it should reference RFC
2459. If we were *only* using the subjectAltName extension then such
a concept could be useful. But at the present time, we don't.

The chapter 2.4, called Uniqueness of names, should be deleted.

I would also propose the following rewording for section 3.1.2:

3.1.2 Subject

   The subject field MUST contain an X.500 distinguished name (DN).
   The subject field from a public key certificate identifies the 
   entity associated with the public key stored in the subject
public 
   key field. The DN MUST be unique for each subject entity
certified 
   by the one CA as defined by the issuer name field. 

   The subject field SHALL contain an appropriate subset of the
   following attributes:

      countryName;
      commonName;
      surname;
      givenName;
      pseudonym;
      serialNumber;
      organizationName;
      organizationalUnitName;
      stateOrProvinceName
      localityName and
      postalAddress.

   Of these attributes, the subject field SHALL include at least one
of
   the following:

      Choice   I:  commonName
      Choice  II:  givenName
      Choice III:  pseudonym

   The subject field MAY contain other attributes.

   Any other attributes that MAY be present in either the subject 
   alternative name extension or the subject directory attributes 
   extension MAY help to give a better human understanding of who 
   the individual really is, but uniqueness of the name is achieved 
   singly by the subject field. 

The countryName attribute value (... then continue with the current
text)

As a result of this, the wording "unmistakable identity" should be
deleted from the whole document. In this way, we will be able to
suppress ambiguous sentences, like in 3.1.2 :

"  Certificates compliant with this profile SHALL at the same time 
   specify a distinguished name and an unmistakable identity of the 
   subject (see 2.4 for definition of distinguished name and 
   unmistakable identity).

   Attributes stored in the subject field SHALL at least form a
   distinguished name of the subject, but they MAY also specify a
   complete unmistakable identity."

I reproduced below an extract from Annex I from the European
Directive on Electronic Signatures:

" Requirements for qualified certificates

Qualified certificates must contain:

(…)

(c)	the name of the signatory or a pseudonym, which shall be
identified as such;"

> Regardless of this I agree with Steve that this issue should be advanced on
> it's own and merged later if it's found relevant to do so.

Anyway, I am preparing some text to describe what a permanent
identifier is and in which OID arc it should be located. This should
be ready at the end of this week. In this way we will be able to
discuss whether the permanent identifier should be, for the time
being, an independent RFC that the QC draft could reference, or
whether it should be an RFC of its own.

Regards,

Denis

> I would therefore request the QC profile to be advanced in it's current
> shape (except for a minor noted update in the reference list).
> 
> Steve:
> How do we proceed.
> 
> /Stefan
> 
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Friday, April 14, 2000 4:36 PM
> > To: Stephen Kent
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Permanent identifiers in QC
> >
> >
> > I agree with Steve.  Note that the CAT Working Group has defined an
> > OTHER-NAME for Kerberos names.
> >
> > Russ
> >
> >
> > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > >Tom,
> > >
> > >I have no problems with the sorts of IDs you proposed in your ASN
> > >GeneralName Other-Name examples. They seem to be consistent with the
> > >arguments that Denis has made for such constructs. However,
> > before we add
> > >these to the updated part 1, I think we need more time to
> > explore the
> > >utility for these name forms.  The debate on the list shows
> > that there are
> > >widely diverse opinions about what such IDs are good for,
> > what scope is
> > >feasible/appropriate, etc.  I'd hesitant to hold up progress on the
> > >revision to 2459 to add this sort of facility which has been
> > proposed only
> > >recently.  That's why several folks have suggested a separate, small
> > >document whoch can be advanced separately, and merged into
> > 2459 if there
> > >is sufficient, consistent support.
> > >
> > >Steve
> >

Date: Tue, 25 Apr 2000 23:05:02 -0700
To: [email-masked]
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: Negative Integers & ASN.1
Cc: [email-masked]

--============_-1255393382==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

there is no specific primitive type for a negative integer. two's 
compliment encoding is used to represent either a positive, zero, or 
negative value.

from the encoding rules

8.3 Encoding of an integer value

8.3.1 The encoding of an integer value shall be primitive. The 
contents octets shall consist of one or more octets.

8.3.2 If the contents octets of an integer value encoding consist of 
more than one octet, then the bits of the first
octet and bit 8 of the second octet
a) shall not all be ones; and
b) shall not all be zero.
NOTE - These rules ensure that an integer value is always encoded in 
the smallest possible number of octets.

8.3.3 The contents octets shall be a two's complement binary number 
equal to the integer value, and consisting of bits 8 to 1 of the 
first octet, followed by bits 8 to 1 of the second octet, followed by 
bits 8 to 1 of each octet in turn up to and including the last octet 
of the contents octets.

NOTE - The value of a two' s complement binary number is derived by 
numbering the bits in the contents octets, starting with bit 1 of the 
last octet as bit zero and ending the numbering with bit 8 of the 
first octet. Each bit is assigned a numerical value of 2 N , where N 
is its position in the above numbering sequence. The value of the 
two' s complement binary number is obtained by summing the numerical 
values assigned to each bit for those bits which are set to one, 
excluding bit 8 of the first octet, and then reducing this value by 
the numerical value assigned to bit 8 of the first octet if that bit 
is set to one.

i assume you must be doing asn.1 encoding by hand; the tools out 
there handle this issue.

if your question was really about how to constrain the value of a 
type to be negative, there is notation to do that also

    hoyt

At 9:14 PM -0700 4/25/00, chandrasekaran natarajan wrote:
>hello,
>
>Thanks Mr.Peter Gutmann and Aram Perez for helping
>me out test my BER/DER Encoding..
>
>I have another doubt....Is there a standard Tag for
>Negative Numbers in ASN.1 and  in general can
>some one help me out on encoding Negative Integers.
>
>Thanks
>
>Chandar
>
>
>
>Send FREE April Fool's Greetings to your friends!
>http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

--============_-1255393382==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Negative Integers &amp;
ASN.1</title></head><body>
<div>there is no specific primitive type for a negative integer. two's
compliment encoding is used to represent either a positive, zero, or
negative value.</div>
<div><br></div>
<div>from the encoding rules</div>
<div><br></div>
<div><font face="Geneva" size="+1" color="#000000"><b>8.3 Encoding of
an integer value</b></font></div>
<div><font face="Geneva" size="+1" color="#000000"><b><br>
8.3.1</b> The encoding of an integer value shall be primitive. The
contents octets shall consist of one or more octets.</font></div>
<div><font face="Geneva" size="+1" color="#000000"><br>
<b>8.3.2</b> If the contents octets of an integer value encoding
consist of more than one octet, then the bits of the first<br>
octet and bit 8 of the second octet<br>
a) shall not all be ones; and<br>
b) shall not all be zero.<br>
</font><font face="Geneva" color="#000000">NOTE - These rules
ensure that an integer value is always encoded in the smallest
possible number of octets.</font></div>
<div><font face="Geneva" color="#000000"><br></font></div>
<div><font face="Geneva" size="+1" color="#000000"><b>8.3.3</b> The
contents octets shall be a two's complement binary number equal to
the integer value, and consisting of bits 8 to 1 of the first octet,
followed by bits 8 to 1 of the second octet, followed by bits 8 to 1
of each octet in turn up to and including the last octet of the
contents octets.</font></div>
<div><font face="Geneva" size="+1" color="#000000"><br></font></div>
<div><font face="Geneva" color="#000000">NOTE - The value of a
two' s complement binary number is derived by numbering the bits in
the contents octets, starting with bit 1 of the last octet as bit
zero and ending the numbering with bit 8 of the first octet. Each bit
is assigned a numerical value of 2<font size="-1"> N</font> , where N
is its position in the above numbering sequence. The value of the
two' s complement binary number is obtained by summing the
numerical values assigned to each bit for those bits which are set to
one, excluding bit 8 of the first octet, and then reducing this value
by the numerical value assigned to bit 8 of the first octet if that
bit is set to one.</font></div>
<div><br></div>
<div>i assume you must be doing asn.1 encoding by hand; the tools out
there handle this issue.</div>
<div><br></div>
<div>if your question was really about how to constrain the value of
a type to be negative, there is notation to do that also</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div>At 9:14 PM -0700 4/25/00, chandrasekaran natarajan wrote:</div>
<blockquote type="cite" cite>hello,<br>
<br>
Thanks Mr.Peter Gutmann and Aram Perez for helping<br>
me out test my BER/DER Encoding..<br>
<br>
I have another doubt....Is there a standard Tag for<br>
Negative Numbers in ASN.1 and&nbsp; in general can<br>
some one help me out on encoding Negative Integers.<br>
<br>
Thanks<br>
<br>
Chandar<br>
<br>
<br>
<br>
Send FREE April Fool's Greetings to your friends!<br>
http://www.whowhere.lycos.com/redirects/A<span
></span>merican_Greetings.rdct</blockquote>
<div><br></div>
</body>
</html>
--============_-1255393382==_ma============--

To: [email-masked]
Date: Tue, 25 Apr 2000 21:16:05 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: Negative Integers & ASN.1
Organization: MailCity  (http://www.mailcity.lycos.com:80)

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

To: [email-masked]
Date: Tue, 25 Apr 2000 21:15:13 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: Negative Integers & ASN.1
Organization: MailCity  (http://www.mailcity.lycos.com:80)

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

To: [email-masked]
Date: Tue, 25 Apr 2000 21:14:57 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: Negative Integers & ASN.1
Organization: MailCity  (http://www.mailcity.lycos.com:80)

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Permanent identifiers in QC
Date: Wed, 26 Apr 2000 00:57:35 +0200

Folks, I've been sort of off-line the last days.

So as caching up with this thread I think we need to decide the progress of
this issue.

I would just want to add an observation regarding NR and Authentication.
The issue is NOT whether permanent identifiers are of value for
Authentication or NR. What IS an issue is whether it is relevant for NR to
be able to compare 2 names in 2 different certificates and ensure that these
certificates identifies the same person EVEN if some parts of the DN is not
matching.

This particular aspect is only raised as a feature for access control (when
an entity changes his certificate, or possesses several certificates with
different DN). In the case of NR and legal signatures, the only issue is to
establish the relation between a certificate and the individual key holder
(regardless of other certificates). Here the current profile provides the
necessary means.

But....

Regardless of this I agree with Steve that this issue should be advanced on
it's own and merged later if it's found relevant to do so.

I would therefore request the QC profile to be advanced in it's current
shape (except for a minor noted update in the reference list).

Steve:
How do we proceed.

/Stefan

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 4:36 PM
> To: Stephen Kent
> Cc: [email-masked]; [email-masked]
> Subject: Re: Permanent identifiers in QC
> 
> 
> I agree with Steve.  Note that the CAT Working Group has defined an 
> OTHER-NAME for Kerberos names.
> 
> Russ
> 
> 
> At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> >Tom,
> >
> >I have no problems with the sorts of IDs you proposed in your ASN 
> >GeneralName Other-Name examples. They seem to be consistent with the 
> >arguments that Denis has made for such constructs. However, 
> before we add 
> >these to the updated part 1, I think we need more time to 
> explore the 
> >utility for these name forms.  The debate on the list shows 
> that there are 
> >widely diverse opinions about what such IDs are good for, 
> what scope is 
> >feasible/appropriate, etc.  I'd hesitant to hold up progress on the 
> >revision to 2459 to add this sort of facility which has been 
> proposed only 
> >recently.  That's why several folks have suggested a separate, small 
> >document whoch can be advanced separately, and merged into 
> 2459 if there 
> >is sufficient, consistent support.
> >
> >Steve
> 

Date: Tue, 25 Apr 2000 09:45:49 +0900
From: Akihiro Takahashi <[email-masked]>
Organization: KCOM MilliCent Project  =?iso-2022-jp?B?RGVwdC4bJEIhIRsoQjAzLTMyNDMtMTE=?=25
To: pkix ML <[email-masked]>
Subject: CA process

Dear Sirs,

Now we are try to make a study for CA business operation procedure
in detail. Is there any mailing list for CA business? Or does anyone
suggest me for how to study it. Cause we would like to start CA 
business in Japan!

"David P. Kemp" wrote:
> 
> > From: Peter Williams <[email-masked]>
> >
> > Does a CA who sends such certificates to a user
> > bear responsibility for the current, individual reliability
> > of any certificate is sends? I.e.
> > can one assume that the subscriber's CA has just checked the
> > certs' non-revoked status, or the provider's contiuing
> > accreditation certificate status, under the CA domain's or
> > another regulators governing policy, prior to inducing others
> > to use or rely on those certificates.
> >
> > Surely, by virtue of supplying CA certifificates to a subscriber
> > at such a critical juncture one is performing an authoritative,
> > legal introduction to the entites bound to the public keys?
> 
> Surely, one is not.  The bag-o'-certs is *nothing* more than a
> pile of information that may save the subscriber the effort of
> looking them up in a directory or elsewhere.  It is entirely
> up to the subscriber to choose a trust anchor and validate all
> certs from that anchor.  If one or more provided certs cannot
> be so validated, I don't see how they can be regarded as
> "introduced" or "considered reliable by a TTP-grade CA".
> 
> What, precisely, is a subscriber supposed to do with intermediate
> (non-self-signed) certificates which have been "introduced" by a CA?
> 
> Dave

From: Michael Myers <[email-masked]>
To: "'Salz, Rich'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: importing from rfc2560
Date: Mon, 24 Apr 2000 12:20:39 -0700

Rich,

Correct.  I discovered this myself while writing the OCSPX I-D.  I got
together with Russ during Adelaide to resolve this.  He allocated the
following OID:

id-mod-ocsp OBJECT IDENTIFIER ::= { id-mod 14 }

where

id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }    -- modules

and

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

It'll find its way into RFC2560 in due course.

Mike

> From: Salz, Rich [mailto:[email-masked]]
> Sent: Monday, April 24, 2000 10:36 AM
> To: [email-masked]'
> Subject: importing from rfc2560
> 
> 
> I'm a neophyte at writing ASN.1, but there doesn't seem to be 
> an OID for me
> to use if I want to import something from OCSP, RFC2560.  Correct?
> 

From: "Salz, Rich" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: importing from rfc2560
Date: Mon, 24 Apr 2000 13:36:01 -0400

I'm a neophyte at writing ASN.1, but there doesn't seem to be an OID for me
to use if I want to import something from OCSP, RFC2560.  Correct?

From: Aram Perez <[email-masked]>
To: [email-masked]
Subject: RE: Testing BER/DER Encoding
Date: Sun, 23 Apr 2000 10:47:19 -0400

> From: chandrasekaran natarajan [mailto:[email-masked]]
> Sent: Saturday, April 22, 2000 3:19 PM
> To: [email-masked]
> Subject: Testing BER/DER Encoding
> 
> 
> hello,
> Please Let me know how to check my BER/DER
> Encodings is correct or not. Is there  a
> tool available for checking the users' BER/DER
> is correct

Check out http://members.xoom.com/Aram_Perez/BERViewer.htm

and http://www.oss.com/products/syntax1.html.

Regards,
Aram Perez

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Testing BER/DER Encoding
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sun, 23 Apr 2000 08:37:17 (NZST)

"chandrasekaran natarajan" <[email-masked]> writes:

>Please Let me know how to check my BER/DER Encodings is correct or not. Is 
>there  a tool available for checking the users' BER/DER is correct

Look for dumpasn1, available from http://www.cs.auckland.ac.nz/~pgut001/.

Peter.

To: [email-masked]
Date: Sat, 22 Apr 2000 12:18:55 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: Testing BER/DER Encoding
Organization: MailCity  (http://www.mailcity.lycos.com:80)

hello,
Please Let me know how to check my BER/DER
Encodings is correct or not. Is there  a
tool available for checking the users' BER/DER
is correct

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

From: Peter Sylvester <[email-masked]>
Date: Fri, 21 Apr 2000 18:52:23 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Missing Protocol ?
Cc: [email-masked]

> > > From: Denis Pinkas <[email-masked]>
> > >
> > > I see no reason for this. AAs (Attributes Authorities) are not the
> > > same like RAs (Registration Authorities).
> > > The response comes from the RA, not an AA. In any case the use of
> > > AAs is not mandated.
> > 
> > It's a question of assurance.  If you trust a directory, you don't need
> > signed attributes.  I lean towards end-to-end security whenever
> > possible, and therefore prefer the RA to sign attributes rather than
> > having the directory dish out unprotected information.  If the
> > authoritative RA database is available online, there is little reason
> > to prefer signed over unsigned.  But as soon as the information is
> > replicated, cached, passed along, or otherwise distributed, the RA's
> > signature becomes helpful.  When the RA signs attributes, it becomes,
> > by definition, an AA.
> 
> Certainly not. Using AC mandates a very precise data structure. So
> it is not because the answer is signed that the RA becomes an AA.
This has nothing to do with the content of the AC. It may be someone
else that the original RA, that creates the AC, but that's probably
not the slightly more difficult situation both of you had in mind.
 
It was discussed that an attrib cert could be appropriate vehicle to carry
a statement of the kind:

  We, the 'issuer' declare (sign) that  'holder' has been registered
  and we have stored the following 'attributes'.
  
Attributes are defined by oids, the CPS of the RA would define the semantics.
the requester can make a request without knowing the schema of the data.

It seems thus possible to me that the RA information can be represented
in an attrib cert.

If so, what does this tell us about the RA caracteristique of being an AA.
I don't care. 

> Note that the RA may respond without any signature and that the
> security may be provided using, e.g. TLS.

What you are saying here is very strange: A judge does not just want
to read a data base, but wants to create a verifiable decision.

There is not just 'one security'. The security of the transport of the
information is something else than the security of the objects. 

There is also the engagement / guarantee implied by the signature of the RA. 

It may be required that the requests/responses need to be archived
The certificate owner may have the right that the RA prooves exactly to whom the
information have been given, and why. There may be strict privacy laws, and
just standard security/audit rules, etc. 
This may mean that the transaction result may need to stored encrypted,
etc.  

It may be also useful to have a reponse: "We, the RA declare that YOU, the requester,
has asked at date X to obtain information about certuser XXXX, we delivered the
following information at date Y to You, you are already the 4711th one, we have
registered the transaction under id 123465." 

Now you can select your favorite more or less secure query protocol
or/and data format, e.g.:
LDAP, CMP++, CMC++ OCSP-Y-NOT, SCVP++, BERT++, DVCS, SNMP, DAP, YASSQPI, 
XML-DIGSIG/XER, POLICE/BLOCKS, JUDGE/SMIME, ... 

> Anyway the intent is not to place that information in multiple
> untrusted Directories, but to query one server (ain the same way
> this is done for OCSP). The idea is to allow to locally store that
> information in some data base that could be queried using LDAP.

This is an implementation detail of the RA. You could have:

'select * from RABASE where certhash=XXXXXXX and serialnumber=1234'

Why does all that need to be online with a direct response. Before handing out
these information, a human intervention may be required, or the information
may not be available online. someone might need to open a safe and get the
required archive cd. 

 cat cdrom/XXXXXXX/1234 | sign+-crypt+log ... 

Thus you should consider to make the transaction transport independant
(mail, http, blocks, pigeons + paper copy).   

P

Date: Fri, 21 Apr 2000 16:24:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Missing Protocol ?

> > From: Denis Pinkas <[email-masked]>
> >
> > I see no reason for this. AAs (Attributes Authorities) are not the
> > same like RAs (Registration Authorities).
> > The response comes from the RA, not an AA. In any case the use of
> > AAs is not mandated.
> 
> It's a question of assurance.  If you trust a directory, you don't need
> signed attributes.  I lean towards end-to-end security whenever
> possible, and therefore prefer the RA to sign attributes rather than
> having the directory dish out unprotected information.  If the
> authoritative RA database is available online, there is little reason
> to prefer signed over unsigned.  But as soon as the information is
> replicated, cached, passed along, or otherwise distributed, the RA's
> signature becomes helpful.  When the RA signs attributes, it becomes,
> by definition, an AA.

Certainly not. Using AC mandates a very precise data structure. So
it is not because the answer is signed that the RA becomes an AA.
Note that the RA may respond without any signature and that the
security may be provided using, e.g. TLS.

Anyway the intent is not to place that information in multiple
untrusted Directories, but to query one server (ain the same way
this is done for OCSP). The idea is to allow to locally store that
information in some data base that could be queried using LDAP. 

Regards,

Denis

> Regards,
> Dave

Date: Fri, 21 Apr 2000 09:50:00 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Missing Protocol ?
To: [email-masked]
Content-MD5: WxCwg+L7wotBd6v5yiN0WQ==

> From: Denis Pinkas <[email-masked]>
> 
> I see no reason for this. AAs (Attributes Authorities) are not the
> same like RAs (Registration Authorities).
> The response comes from the RA, not an AA. In any case the use of
> AAs is not mandated.

It's a question of assurance.  If you trust a directory, you don't need
signed attributes.  I lean towards end-to-end security whenever
possible, and therefore prefer the RA to sign attributes rather than
having the directory dish out unprotected information.  If the
authoritative RA database is available online, there is little reason
to prefer signed over unsigned.  But as soon as the information is
replicated, cached, passed along, or otherwise distributed, the RA's
signature becomes helpful.  When the RA signs attributes, it becomes,
by definition, an AA.

Regards,
Dave

Date: Fri, 21 Apr 2000 09:34:14 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [email-masked]
Content-MD5: vPx5LDvtuJg3bnB45dFS2Q==

Agree with all 3.  However, a CPS may require acceptance
actions that are not required by the CMP technical
specification.

If the CPS requires the EE's UA to validate EE's certificate
as a condition of acceptance, the UA will need sufficient
information from some source to perform the validation.
CMP, or PKIX operational protocols, or offline operations
could provide that information.

It's up to an accrediting body, not the IETF, to determine
if all accreditable CPSs must require (2).

Dave

> From: Peter Williams <[email-masked]>
> 
> Alex,
> 
> We have seemingly cleared up or determined
> three technical points from the discussion. Do
> say if any description below is not
> correct - in your view.
> 
> (1) a CMP responder does not need to send any
> particular cert path to the subscriber, when
> returning the EE cert for EE acceptance. The UA
> should not assume presence of any particular
> certs, including the CA cert or any superior
> certs in the domain's trust network, in the 
> message field in discussion. Futhermore, any
> certs that are sent are in bag order.
> 
> (2) According to CMP designers, the UA does not
> need to verify the signature of the 
> EE certificate upon initial receipt (which
> in many enrollment circumstances will constitute the
> moment of making an acceptance determination.) Such
> UA does not therefore need any certificate
> paths or CRLs ( or othe status source) at that 
> point in time.
> 
> (3) CMP's CRL retrieval service is not meant
> to be a PKIX operational protocol. It is not
> clear if a conforming CMP implementation and CA
> will provide this facility.
> 
> Peter.

Date: Fri, 21 Apr 2000 09:20:32 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [email-masked]
Content-MD5: 43Yhi3wdMg2aLTieCdn/fg==

Hi Peter,

I believe there is an issue of "best commercial practices"
here.  If a building contractor presented a forged paper license
or misappropriated the identity of a legitimately licensed
contractor, I'm 100% certain that is a misrepresentation of
fact.  If the contractor presented a legitimate license, within
its printed validity interval but which had been suspended/revoked,
a "90% misrepresentation" has occurred.  The homeowner
has a 10% responsibility to check references, the BBB, and the
contractor's professional association, but I suspect a judge
would not penalize the homeowner too severely for not having
done so.

But accepted practice is for police officers to verify the
putative validity of plates and drivers licenses with a radio
call.  And accepted practice for PKIX clients should be to
validate certificates before relying upon them.  If that is
true, there is fault with the CA for misrepresentation, and
fault (at least 50%) with the subscriber for lack of due diligence.
The CA is not blameless, and can be punished (given a black
mark on the compliance audit, or de-certified) by a regulating
body.  But, IMO, the only damages the subscriber suffers is
the fact that subscriber's certificate will not be accepted
by RPs.  The CA is responsible for promises made to deliver
a valid certificate and business lost as a result of failure
to deliver what was promised.  But at the moment of delivery,
(again IMO, IANAL!) the subscriber assumes nearly all the
responsibility for not properly validating the cert as part
of acceptance.

Regards,
Dave

> From: Peter Williams <[email-masked]>
> To: "'David P. Kemp'" <[email-masked]>, [email-masked]
> Subject: RE: What is the order of certificates in a certificate chain?
> Date: Thu, 20 Apr 2000 19:57:30 -0700
> 
> Hi David:
> 
> Consider the following reasoning:-
> 
> A CA, in the PKIX model, may be accredited - something
> that is signaled via the issuance of a cross-certificate
> or similar.
> 
> If a (trusted) CA quotes such a cross-certificate during
> certificate application procedures, it is
> essentially representing the validity of the underlying
> accreditation. A CA which quoted a revoked
> accreditation cross-certificate would
> be likely acting in a manner which is a mis-representation
> of fact, surely.
> 
> If a building contractor came to your house,
> presented an official and legally-recognised
> paper license to do electrical work, and you subsequently 
> determine that the license had been revoked in
> the license registry prior to presentation of the
> paper during contract negotiation, would you not feel a 
> simple mis-representation had occured?
> 
> Could a regulator not punish that contractor for
> not suspending licensed work - and/or falsely
> imputing a licensed standing?
> 
> I would think that a best practices Internet CA has 
> a simple professional if not a legal duty to ensure that
> it does not provide false information to a subscriber 
> during CMP; especially information that might prejudice 
> the determination of that subscriber when establishing 
> the initial accuracy of a certificate that will bind 
> him/her at NR grade of proof - following formal 
> acceptance of that certificate.

Date: Fri, 21 Apr 2000 09:14:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Missing Protocol ?

David,

Let me comment and rephrase what you say.

> Denis,
> 
> If the information is NOT in a public key certificate, and the
> information IS to be provided electronically instead of using methods
> from the 60's, then the question is how to provide it.

Correct.

> I'm with Bob and Peter: the directory is the answer and no new
> protocol is needed.  

LDAP (no the directory) is one answer. Then a schema and the
definition of attributes is needed.

> If there are attributes defined for passport
> number/validity, bank account number, optically-scanned document, etc,
> then those attributes can be stored in the directory either in unsigned
> normal form 

This is/was the only case I considered.

> or in signed attribute certificates.

I see no reason for this. AAs (Attributes Authorities) are not the
same like RAs (Registration Authorities).
The response comes from the RA, not an AA. In any case the use of
AAs is not mandated.

> No matter how new attribute certificates are, they are more mature than
> this undefined 'missing protocol'.  It would be most productive to use
> ACs and/or directories as is, and focus energy on establishing the catalog
> of attribute definitions.

I agree that we could work on the catalog of attribute definitions.
The only problem I see is that the requester only knows the class of
information he is looking at, while LDAP provides very precise
attributes. This attributes loosely match the classes that are
requested. If we can provide a way for getting this loose mapping,
then we are close to a solution. :-)

Regards,

Denis

> Dave
> 
> > From: Denis Pinkas <[email-masked]>
> >
> > Attribute Certificates are quite new and new [not] frequently used (if
> > used). As stated above, the problem does not directly relate to
> > Attribute Certificates.
> >
> > > - There are methods/protocols to "publish" certificates, or to give
> > >   controlled and secured access to them.
> >
> > Yes, but the information that is needed is NOT in the certificate.
> >
> > > > As a bottom line: if a protocol is not going to be used frequently, and we
> > > > can get by without it for occasional need, do we need the protocol at all?
> >
> > When we will have a significant deployment of a world-wide PKI, this
> > protocol will be more and more useful/needed. We are trying to
> > anticipate the needs.
> >
> > Regards,
> >
> > Denis
> >
> > > I think we don't need a new one.
> > >
> > > Peter

From: Peter Williams <[email-masked]>
To: "'Alex Deacon'" <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 20 Apr 2000 20:01:15 -0700

Alex,

We have seemingly cleared up or determined
three technical points from the discussion. Do
say if any description below is not
correct - in your view.

(1) a CMP responder does not need to send any
particular cert path to the subscriber, when
returning the EE cert for EE acceptance. The UA
should not assume presence of any particular
certs, including the CA cert or any superior
certs in the domain's trust network, in the 
message field in discussion. Futhermore, any
certs that are sent are in bag order.

(2) According to CMP designers, the UA does not
need to verify the signature of the 
EE certificate upon initial receipt (which
in many enrollment circumstances will constitute the
moment of making an acceptance determination.) Such
UA does not therefore need any certificate
paths or CRLs ( or othe status source) at that 
point in time.

(3) CMP's CRL retrieval service is not meant
to be a PKIX operational protocol. It is not
clear if a conforming CMP implementation and CA
will provide this facility.

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 4:40 PM
To: 'Peter Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

Hi Peter, 

"Registering user agents" should not make any assumptions as to the contents
of the various cert bags in use today.  A CA (or RA) may choose to include
what it beleives to be a set useful certificates that the client will need
to perform proper chain validation.  In some cases, such as CMS, CRL's may
also be conveyed. 

However the CA or RA makes no assersitions as to the reliability/validity of
these objects.  From what I understand of the classic X.509 model, it is
always up to the client to determine the validity certs.   A client may
choose to utilize the certs provided in these cert bags, however it may also
decide to drop them on the floor and use other methods for cert (and crl)
discovery such as LDAP and other methods of certificate validation such as
OCSP.  I would guess that the pki policy under which these clients operate
would influence these kind of decisions....

Alex

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 12:12 PM
To: 'Alex Deacon'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?

Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?

Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Peter Williams <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, [email-masked]
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 20 Apr 2000 19:57:30 -0700

Hi David:

Consider the following reasoning:-

A CA, in the PKIX model, may be accredited - something
that is signaled via the issuance of a cross-certificate
or similar.

If a (trusted) CA quotes such a cross-certificate during
certificate application procedures, it is
essentially representing the validity of the underlying
accreditation. A CA which quoted a revoked
accreditation cross-certificate would
be likely acting in a manner which is a mis-representation
of fact, surely.

If a building contractor came to your house,
presented an official and legally-recognised
paper license to do electrical work, and you subsequently 
determine that the license had been revoked in
the license registry prior to presentation of the
paper during contract negotiation, would you not feel a 
simple mis-representation had occured?

Could a regulator not punish that contractor for
not suspending licensed work - and/or falsely
imputing a licensed standing?

I would think that a best practices Internet CA has 
a simple professional if not a legal duty to ensure that
it does not provide false information to a subscriber 
during CMP; especially information that might prejudice 
the determination of that subscriber when establishing 
the initial accuracy of a certificate that will bind 
him/her at NR grade of proof - following formal 
acceptance of that certificate.

----

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, April 20, 2000 8:32 AM
To: [email-masked]
Subject: RE: What is the order of certificates in a certificate chain?

> From: Peter Williams <[email-masked]>
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?

Surely, one is not.  The bag-o'-certs is *nothing* more than a
pile of information that may save the subscriber the effort of
looking them up in a directory or elsewhere.  It is entirely
up to the subscriber to choose a trust anchor and validate all
certs from that anchor.  If one or more provided certs cannot
be so validated, I don't see how they can be regarded as
"introduced" or "considered reliable by a TTP-grade CA".

What, precisely, is a subscriber supposed to do with intermediate
(non-self-signed) certificates which have been "introduced" by a CA?

Dave

Date: Thu, 20 Apr 2000 14:34:38 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Missing Protocol ?
To: [email-masked]
Content-MD5: 7uCdwWMBViBl6dXsVZ1aXw==

Denis,

If the information is NOT in a public key certificate, and the
information IS to be provided electronically instead of using methods
from the 60's, then the question is how to provide it.

I'm with Bob and Peter: the directory is the answer and no new
protocol is needed.  If there are attributes defined for passport
number/validity, bank account number, optically-scanned document, etc,
then those attributes can be stored in the directory either in unsigned
normal form or in signed attribute certificates.

No matter how new attribute certificates are, they are more mature than
this undefined 'missing protocol'.  It would be most productive to use
ACs and/or directories as is, and focus energy on establishing the catalog
of attribute definitions.

Dave

> From: Denis Pinkas <[email-masked]>
>
> Attribute Certificates are quite new and new [not] frequently used (if
> used). As stated above, the problem does not directly relate to
> Attribute Certificates.
> 
> > - There are methods/protocols to "publish" certificates, or to give
> >   controlled and secured access to them.
> 
> Yes, but the information that is needed is NOT in the certificate.
> 
> > > As a bottom line: if a protocol is not going to be used frequently, and we
> > > can get by without it for occasional need, do we need the protocol at all?
> 
> When we will have a significant deployment of a world-wide PKI, this
> protocol will be more and more useful/needed. We are trying to
> anticipate the needs.
> 
> Regards,
> 
> Denis
>  
> > I think we don't need a new one.
> > 
> > Peter

Date: Thu, 20 Apr 2000 18:44:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Missing Protocol ?

Michael and Peter,

I use this E-mail to comment on your answers.

> > I am not sure that the problem the proposed protocol is addressing is the
> > real problem.
> 
> I realised that Denis and I had been talking about two different things.
> So be it.
> 
> It seems that the interest it to 'publish' some attributes that are
> kept by the RA/CA....

Correct.

> > I do not think that the protocol will be something of a frequent use: If an
> > entity can not be uniquely and unambiguously identified without some extra
> > 'with-the-beard' information, that information should be present in the
> > entity's certificate. 

Two arguments: 
1) The European Directive explicitly allows for the use of a
pseudonym. 
2) There is no requirement at all that the information that is
present in the certificate allows to identify unambiguously the
person.

> > You do not want to reach out and ask an RA for extra
> > details about the entity every time you deal with that entity. It is just
> > going to be a pain. Therefore, I do not think we have a real requirement
> > here. Passing it over to the "unique ID" thread :)
> 
> ... a passport number, its validity date, my bank account number, etc. are
> not necessarily available in the ID cert, but they can be made available
> in one or more attribute certs, for example.
> 
> I had in mind a completely unstructured set of scanned copies of
> paper documents, 

Yes, this is a good example.

> but even that could be encapsulated in an attribute cert.

I do not think so. None of that information needs to be in an
Attribute Certificate. That information is useful for Public Key
certificates and does not relate to Attribute Certificates.

> > I am not convinced that the protocol is necessary for infrequent use either:
> > When a judge or police, or anybody else needs more information about the
> > entity, an RA can be contacted directly. You do not really need a protocol.
> 'contact directly' means what? ...
> 
> > A judge, police etc can do it by phone, by fax, by email or by face to face.
> > As they do it now, conveniently and simple enough.

Everything can be done slowly by the communication means from the
60's. :-) We are trying to use faster techniques for the millenium.
:-)

> This is the bottom line of the question. To replace existing methods, for example:
> 
> - An RA can always issue an attribute cert for all the attributes that they
>   store, be it just as a convenient way to fix the content of its user data base,
>   or be it to inform the user about what has been stored about him.

Attribute Certificates are quite new and new frequently used (if
used). As stated above, the problem does not directly relate to
Attribute Certificates.

> - There are methods/protocols to "publish" certificates, or to give
>   controlled and secured access to them.

Yes, but the information that is needed is NOT in the certificate.

> > As a bottom line: if a protocol is not going to be used frequently, and we
> > can get by without it for occasional need, do we need the protocol at all?

When we will have a significant deployment of a world-wide PKI, this
protocol will be more and more useful/needed. We are trying to
anticipate the needs.

Regards,

Denis
 
> I think we don't need a new one.
> 
> Peter
>

Date: Fri, 21 Apr 2000 00:40:22 +0900
From: "Kwon, YongChul" <[email-masked]>
To: [email-masked]
Subject: Re: about Basic constraints
Organization: Initech, Inc

Sorry, I found what I want in RFC-2459 and its son. :-)

Date: Thu, 20 Apr 2000 11:31:57 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [email-masked]
Content-MD5: qxX23CU7+wX1zAuK2pSJZw==

> From: Peter Williams <[email-masked]>
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?

Surely, one is not.  The bag-o'-certs is *nothing* more than a
pile of information that may save the subscriber the effort of
looking them up in a directory or elsewhere.  It is entirely
up to the subscriber to choose a trust anchor and validate all
certs from that anchor.  If one or more provided certs cannot
be so validated, I don't see how they can be regarded as
"introduced" or "considered reliable by a TTP-grade CA".

What, precisely, is a subscriber supposed to do with intermediate
(non-self-signed) certificates which have been "introduced" by a CA?

Dave

Reply-To: <[email-masked]>
From: "Kwon, YongChul" <[email-masked]>
To: <[email-masked]>
Subject: about Basic constraints
Date: Thu, 20 Apr 2000 23:43:40 +0900
Importance: Normal

I'm afraid of asking this so-old question, but it's really confusing. :-(

Let's assume some scinario

CA A certificate contains basic constraints of pathlen 1.
CA B have a certificate issued by CA A and it contains no basic 
constraints. If basic constraints doesn't appear, It can issue CA
certificates which can be used to signing CA certificate(able 
to sign CA certificate) again and again.

Then I have a question, in a certain certificate validation chain
basic constraints of sub CA just overide the parent's?

Thanks a lot.

---------------
Kwon, YongChul([email-masked])
Institute of Researching Security Technology 
    of  Initiative Technology, Inc.

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: processing Name in certificate 
Date: Thu, 20 Apr 2000 11:49:38 +0100

"Kwon, YongChul" writes:
>When converting Name(DN) in certificate to LDAP DN,
>
>What is the order of Name?

It's easy to see why you're confused, and you're certainly not alone
on this, as there are differing external orders of representation of
DNs around.

However, you need to know that the sequence of RDNs in the
certificate's ASN.1 encoding of Name is unambiguous; the Name
represents a path through a (putative) hierarchy, with the first
member of the sequence is the most significant, and the last the least
significant.

X.509 Certificates are defined (surprise!) by the X.509 standard,
which does not explicitly spell out the order, because it is defined
in X.501, referenced as normative by X.509, and hence further
definition would be redundant in X.509.  Since RFC 2459 (and other
profiles issued by the PKIX group) profiles the use of X.509
certificates, the X.501 definition applies there too in the absence of
any statement to the contrary.

Given that this internal ordering is well-defined, the issue becomes
one of external presentation and ensuring that whatever ordering you
use is mapped correctly onto the internal ASN.1 encoded order.

An LDAP DN string, defined by RFC 1779, is encoded in the reverse
order (least significant first), and passes across the LDAP protocol
in this order UNLESS it has been encoded in a certificate or some
similar object whose value is an binary ASN.1 encoding of a DN.

>if Name in certificate stored in order likes "C L ST O OU ...",
>
>Should it be converted in LDAP DN likes "...OU O ST L C"?

Yes.

>or just same order in RDN sequence?

No.

>or It's free for implementer?( I really don't want that. :-( )

No, it's well-defined.  Just confusing.

David.

[email-masked]

Reply-To: <[email-masked]>
From: "Kwon, YongChul" <[email-masked]>
To: <[email-masked]>
Subject: processing Name in certificate
Date: Thu, 20 Apr 2000 17:48:05 +0900
Importance: Normal

When converting Name(DN) in certificate to LDAP DN,

What is the order of Name?

if Name in certificate stored in order likes "C L ST O OU ...",

Should it be converted in LDAP DN likes "...OU O ST L C"?

or just same order in RDN sequence?

or It's free for implementer?( I really don't want that. :-( )

Thanks a lot!

---------------
Kwon, YongChul([email-masked])
Institute of Researching Security Technology 
    of  Initiative Technology, Inc.

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 Apr 2000 10:11:49 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: RE: Missing Protocol ?
Cc: [email-masked], [email-masked]

> I am not sure that the problem the proposed protocol is addressing is the
> real problem.

I realised that Denis and I had been talking about two different things. 
So be it. 

It seems that the interest it to 'publish' some attributes that are
kept by the RA/CA....

> 
> I do not think that the protocol will be something of a frequent use: If an
> entity can not be uniquely and unambiguously identified without some extra
> 'with-the-beard' information, that information should be present in the
> entity's certificate. You do not want to reach out and ask an RA for extra
> details about the entity every time you deal with that entity. It is just
> going to be a pain. Therefore, I do not think we have a real requirement
> here. Passing it over to the "unique ID" thread :)

... a passport number, its validity date, my bank account number, etc. are
not necessarily available in the ID cert, but they can be made available
in one or more attribute certs, for example. 

I had in mind a completely unstructured set of scanned copies of
paper documents, but even that could be encapsulated in an attribute cert.

> I am not convinced that the protocol is necessary for infrequent use either:
> When a judge or police, or anybody else needs more information about the
> entity, an RA can be contacted directly. You do not really need a protocol.
'contact directly' means what? ...

> A judge, police etc can do it by phone, by fax, by email or by face to face.
> As they do it now, conveniently and simple enough. 

This is the bottom line of the question. To replace existing methods, for example:

- An RA can always issue an attribute cert for all the attributes that they
  store, be it just as a convenient way to fix the content of its user data base,
  or be it to inform the user about what has been stored about him.

- There are methods/protocols to "publish" certificates, or to give
  controlled and secured access to them.

> 
> As a bottom line: if a protocol is not going to be used frequently, and we
> can get by without it for occasional need, do we need the protocol at all?

I think we don't need a new one. 

Peter

From: Michael Zolotarev <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked], xme <[email-masked]>
Subject: RE: Missing Protocol ?
Date: Thu, 20 Apr 2000 11:53:09 +1000

I am not sure that the problem the proposed protocol is addressing is the
real problem.

I do not think that the protocol will be something of a frequent use: If an
entity can not be uniquely and unambiguously identified without some extra
'with-the-beard' information, that information should be present in the
entity's certificate. You do not want to reach out and ask an RA for extra
details about the entity every time you deal with that entity. It is just
going to be a pain. Therefore, I do not think we have a real requirement
here. Passing it over to the "unique ID" thread :)

I am not convinced that the protocol is necessary for infrequent use either:
When a judge or police, or anybody else needs more information about the
entity, an RA can be contacted directly. You do not really need a protocol.
A judge, police etc can do it by phone, by fax, by email or by face to face.
As they do it now, conveniently and simple enough. 

As a bottom line: if a protocol is not going to be used frequently, and we
can get by without it for occasional need, do we need the protocol at all?

Regards
Michael

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 19, 2000 11:15 PM
> To: Peter Sylvester
> Cc: [email-masked]
> Subject: Re: Missing Protocol ?
> 
> 
> Peter,
> 
> <snip>
> 
> > - NOTHING is added to the protocol.
> >   The request is 'validate public key certificate':
> >  'Tell me why you think this cert is good'.
> 
> This NOT the question. 
> 
> >   Please explain why you think you ask for something else?
> 
> You give a certificate reference and you would ONLY like to know
> some (or all) the registration information that was provided at the
> time of registration.
> 
> <snip>
> 
> > Are you asking for a service that send the document or the 
> signatures
> > to a server, and depending on the signature, the server returns
> > some information about it:
> > 
> > "Please tell me what you think about these signature and provide as
> >  much information as you may want to give me."
> 
> No. See the question above.
> 
> > I can't resist: 'vsd' in dvcs is one vehicle to ask this question.
> 
> I can't resist either: DVCS is NOT the right vehicule for this.
> 
> Regards,
> 
> Denis
> 

From: Alex Deacon <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:39:39 -0700

Hi Peter, 

"Registering user agents" should not make any assumptions as to the contents
of the various cert bags in use today.  A CA (or RA) may choose to include
what it beleives to be a set useful certificates that the client will need
to perform proper chain validation.  In some cases, such as CMS, CRL's may
also be conveyed. 

However the CA or RA makes no assersitions as to the reliability/validity of
these objects.  From what I understand of the classic X.509 model, it is
always up to the client to determine the validity certs.   A client may
choose to utilize the certs provided in these cert bags, however it may also
decide to drop them on the floor and use other methods for cert (and crl)
discovery such as LDAP and other methods of certificate validation such as
OCSP.  I would guess that the pki policy under which these clients operate
would influence these kind of decisions....

Alex

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 12:12 PM
To: 'Alex Deacon'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?

Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?

Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Peter Williams <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, "'Alex Deacon'" <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:35:20 -0700

Hi Carlisle:

Its always fun to consider the interaction of technical
specification, the role of technical compliance, and the 
policy rules which govern how technology operations
MUST function. Let us address this topic a little more
for the case of validating EE certificates during certificate
acceptance.

One of the things that many reference CPSs require, and Santosh'
and Warwick's (http://www.ietf.org/rfc/rfc2527.txt 4.4) work on CPS 
disclosures highlights,is the notion of "certificate acceptance" by 
subscribers. 

Acceptance is the point where the good work of the CA 
(via CMP or PKCS or Cisco's protocols) in registering and certifying 
public keys (and other data) is checked by the subscriber. This is done
normally PRIOR to publication of the certificatein a repository that then
perform the initial and then ongoing certificate 
management.  Various legal obligations may be passed at the moment 
of acceptance; it is an important step in the legal protocol. Generally, one
 is not authorized to use or rely on the certificate as a 
subscriber - until one has accepted it. 

Certificate acceptance is *specifically* relevant to 
the protocol message under discussion, I would suggest; it is 
the generalization of what CMP is enforcing when the
EE UA accepts/processes the cert response msg. The content
of that response is the specfiic question.

The rules for acceptance of the EE cert are policy-based, of course.

https://www.verisign.com/repository/CPS1.2/CPSCH7.HTM#_toc361807047
specifies one such policy rule system, into which a particular 
configuration of CMP would presumbably have to fit. It is not CMP
that drives policy design; policy drives how CMP is used
to satisfy the technology-independent/protocol-independent
policy rules.

In general, "reasonable acceptance" require a susbcriber validate 
the certificate upon initial receipt - after all, its
signature may fail verification, or the data contained
within may be erroneous, or, you just change your
mind about binding yourself to the CA's legal agreement.
In policy-cases such as VeriSign, furthermore, **only
upon** acceptance may the next phase of CMP go ahead
wherein the certificate is published to the primary
and official respository by the CA's CMP instance.

Now, my claim is, surely with very significant
relevance, that the only way to validate an EE cert 
at the moment of acceptance, is to traverse some trust 
chain upto a trust-anchor.

If I understand CMP and the conversation here,
it is understood that the pubKeys data element will
communicate those certified keys that the EE needs to validate
its own key, during acceptance and/or at later
points of time.

>From you mail, it is now implied that the same
EE UA may be required - at the point of acceptance
(namely processing the CMP Response) - 
to obtain CRLs from one or more CAs via CMP, so that
it can indeed validate the certificate it
has just been sent for acceptance, and
(as necessary) confirm the supporting
cerificate chain as required by such
as VeriSign's policy.

https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM#_toc361807054
(see 8.2 for discussion of confirmation, and validation)

At this point, we have one further
techno/policy question. In supplying the
certs necessary for EE cert validation at
the point of acceptance, whose nature largely
**determines** the outcome of acceptance,
what liability does the CA have for
inducing that outcome?... particularly
if it supplies compromised CA certs 
which are revoked or no longer
in good standing in an accreditation
registry?

Peter.

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 1:17 PM
To: 'Alex Deacon'; 'Peter Williams'
Cc: PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

Hi Peter,

Good to hear from you again!

I apologize in advance if I appear unsympathetic to your line of
questioning, but I'm afraid it seems a little bit irrelevant to me.  In most
environments, prudence dictates that you check the validity of a certificate
just prior to using it (i.e., relying upon it), not upon first receipt of
it.  Therefore, in your emphatically fictitious example (!), even if
Verisign wished to attest to the reliability (in some sense) of the supplied
cert path, who is to say that this path is still reliable 10 minutes later
when the newly-initialized EE wants to perform some other action?  (A new
CRL might have been published by then listing one or more of these certs as
revoked, or the relevant OCSP responder might give a negative answer due to
a notification of key compromise.)

I can't think of any way in the spec. for the CA to perform "an
authoritative, legal introduction to the entites bound to the public keys",
as you put it.  Nor do I really think there should be.  The purpose of the
supplied bag of certs is to provide helpful information to the EE (e.g.,
"here are the CAs between you and the trust anchor", or "here are the keys
of some other entities that may be useful" (such as a time stamp server, or
an OCSP responder, or whatever)).  When the EE needs to rely on these keys,
it should get the relevant CRLs/ARLs, or contact the relevant responder,
etc., just as it would for any other certs.

Note that CMP does define a CRL request message and a CRL announcement
message that may be used for EE discovery of revocation information, but not
much explanation or detail is given on these messages.  This is primarily
because such functions are more properly the domain of the PKIX operational
protocols, which are specified separately.

Carlisle.

> ----------
> From: 	Peter Williams[SMTP:[email-masked]]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> Some issues:
> 
> Should implementors assume that there are "any
> particular certificates in the caPubs field" - or should
> one assume it may be a "random" bag of any certs
> the CA chooses to send?
> 
> As far as the normative CMP spec is concerned, a registering 
> UA can make no assumption as to the certs that a CA
> populated in caPubs. One cannot build
> a "conforming UA" to expect "a subscriber's 'cert path' up
> a trust hierarchy" for example - as neither all 
> CMP conforming implementations nor
> the Certification domains to which the CMP module provides
> service may provide this optional, highly policy-specific 
> construct.
> 
> Now, consider the other side of the coin.  Assume
> a CA's configuration of a CMP implementation chooses to
> send a given set of certificates - out of which one can form 
> a "trust path",  where the CA's policy defines what a "path" 
> is for use in policy-compliant "certificate validation".
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?
> 
> 
> Scenario:
> 
> Lets take a scenario, mostly real - which flexes
> the 2459 and CMP model according to these issue
> to see if it all really works when we get out of the 
> realm of paper architectures:
> 
> I enroll for a VeriSign class 1 cert as a subcriber,
> for the (fictional?) "US govt interoperable" type of 
> key certification service.
> 
> Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
> 1000 other (otherwise) equivalent providers of certs - is because 
> US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
> (FICTIONALLY) recognises Class 3 organizational certs for ... some
> important,
> high-value G2B application.
> 
> Now I assume that a VeriSign-policy specific CMP registration response
> would send me, in bag order, at least the various
> non-PCA intermediate CA certs from VeriSign's trust hierachy,
> plus the cross-certificate issued by US gov to
> the VeriSign Class 3 PCA. After all, this is what I really
> need.
> 
> If VeriSign does send me such an authoritative cross-certificate, can I 
> assume its (a) valid and (b) the recognition (accreditation)
> status of VeriSign Class 3 PCA domain, before US govt, is
> in good standing at that moment? 
> 
> Do I need to check revocation status of the cert before making
> such a judgement, in counterpoint?
> 
> Similarly, if VeriSign (my choice of TTP provider) sends me a 
> subordinate CA certificate that corresponds to a non-VeriSign 
> operator (British Telecommunications, say) is that an implied
> representation that the operator is in current compliance with 
> VeriSign's CPS/policy, and I can rely upon that implicit signal?
> 
> 
> Summary of questions:
> 
> Surely, to summarize, 
> 
> (A) A TTP-grade CA would only send a 
> critically-important certificate that is "reliable" - characteried 
> by actual and current compliance with policy, accreditation, and similar
>  programs that denote an operators trust standing in the eyes of auditors
> and similar independents?
> 
> (B) To check such certificates for reliablity, would one
> need access to the various CRLs, or similar status
> sources. Should CMP be supplying these, too? Or, do
> we assume the registering UA will do a (not CMP-specified)
> action to collect and process those CRLs before completing
> the registration process, and formally "accepting" the supplied
> subscriber (EE) certificate and the ancillary caPubs or
> other similar information needed to validate that certificate?
> 
> Peter.
> 
> From: Alex Deacon [mailto:[email-masked]]
> Sent: Wednesday, April 19, 2000 11:05 AM
> To: 'Christopher Williams'; PKIX Mailing List
> Subject: RE: What is the order of certificates in a certificate chain?
> 
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> From: Christopher Williams [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
> 

From: Carlisle Adams <[email-masked]>
To: "'Alex Deacon'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:17:10 -0400

Hi Peter,

Good to hear from you again!

I apologize in advance if I appear unsympathetic to your line of
questioning, but I'm afraid it seems a little bit irrelevant to me.  In most
environments, prudence dictates that you check the validity of a certificate
just prior to using it (i.e., relying upon it), not upon first receipt of
it.  Therefore, in your emphatically fictitious example (!), even if
Verisign wished to attest to the reliability (in some sense) of the supplied
cert path, who is to say that this path is still reliable 10 minutes later
when the newly-initialized EE wants to perform some other action?  (A new
CRL might have been published by then listing one or more of these certs as
revoked, or the relevant OCSP responder might give a negative answer due to
a notification of key compromise.)

I can't think of any way in the spec. for the CA to perform "an
authoritative, legal introduction to the entites bound to the public keys",
as you put it.  Nor do I really think there should be.  The purpose of the
supplied bag of certs is to provide helpful information to the EE (e.g.,
"here are the CAs between you and the trust anchor", or "here are the keys
of some other entities that may be useful" (such as a time stamp server, or
an OCSP responder, or whatever)).  When the EE needs to rely on these keys,
it should get the relevant CRLs/ARLs, or contact the relevant responder,
etc., just as it would for any other certs.

Note that CMP does define a CRL request message and a CRL announcement
message that may be used for EE discovery of revocation information, but not
much explanation or detail is given on these messages.  This is primarily
because such functions are more properly the domain of the PKIX operational
protocols, which are specified separately.

Carlisle.

> ----------
> From: 	Peter Williams[SMTP:[email-masked]]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> Some issues:
> 
> Should implementors assume that there are "any
> particular certificates in the caPubs field" - or should
> one assume it may be a "random" bag of any certs
> the CA chooses to send?
> 
> As far as the normative CMP spec is concerned, a registering 
> UA can make no assumption as to the certs that a CA
> populated in caPubs. One cannot build
> a "conforming UA" to expect "a subscriber's 'cert path' up
> a trust hierarchy" for example - as neither all 
> CMP conforming implementations nor
> the Certification domains to which the CMP module provides
> service may provide this optional, highly policy-specific 
> construct.
> 
> Now, consider the other side of the coin.  Assume
> a CA's configuration of a CMP implementation chooses to
> send a given set of certificates - out of which one can form 
> a "trust path",  where the CA's policy defines what a "path" 
> is for use in policy-compliant "certificate validation".
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?
> 
> 
> Scenario:
> 
> Lets take a scenario, mostly real - which flexes
> the 2459 and CMP model according to these issue
> to see if it all really works when we get out of the 
> realm of paper architectures:
> 
> I enroll for a VeriSign class 1 cert as a subcriber,
> for the (fictional?) "US govt interoperable" type of 
> key certification service.
> 
> Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
> 1000 other (otherwise) equivalent providers of certs - is because 
> US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
> (FICTIONALLY) recognises Class 3 organizational certs for ... some
> important,
> high-value G2B application.
> 
> Now I assume that a VeriSign-policy specific CMP registration response
> would send me, in bag order, at least the various
> non-PCA intermediate CA certs from VeriSign's trust hierachy,
> plus the cross-certificate issued by US gov to
> the VeriSign Class 3 PCA. After all, this is what I really
> need.
> 
> If VeriSign does send me such an authoritative cross-certificate, can I 
> assume its (a) valid and (b) the recognition (accreditation)
> status of VeriSign Class 3 PCA domain, before US govt, is
> in good standing at that moment? 
> 
> Do I need to check revocation status of the cert before making
> such a judgement, in counterpoint?
> 
> Similarly, if VeriSign (my choice of TTP provider) sends me a 
> subordinate CA certificate that corresponds to a non-VeriSign 
> operator (British Telecommunications, say) is that an implied
> representation that the operator is in current compliance with 
> VeriSign's CPS/policy, and I can rely upon that implicit signal?
> 
> 
> Summary of questions:
> 
> Surely, to summarize, 
> 
> (A) A TTP-grade CA would only send a 
> critically-important certificate that is "reliable" - characteried 
> by actual and current compliance with policy, accreditation, and similar
>  programs that denote an operators trust standing in the eyes of auditors
> and similar independents?
> 
> (B) To check such certificates for reliablity, would one
> need access to the various CRLs, or similar status
> sources. Should CMP be supplying these, too? Or, do
> we assume the registering UA will do a (not CMP-specified)
> action to collect and process those CRLs before completing
> the registration process, and formally "accepting" the supplied
> subscriber (EE) certificate and the ancillary caPubs or
> other similar information needed to validate that certificate?
> 
> Peter.
> 
> From: Alex Deacon [mailto:[email-masked]]
> Sent: Wednesday, April 19, 2000 11:05 AM
> To: 'Christopher Williams'; PKIX Mailing List
> Subject: RE: What is the order of certificates in a certificate chain?
> 
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> From: Christopher Williams [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
> 

From: Peter Williams <[email-masked]>
To: "'Alex Deacon'" <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 12:12:15 -0700

Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?

Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?

Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Carlisle Adams <[email-masked]>
To: "'Christopher Williams'" <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>, "'Alex Deacon'" <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 14:40:02 -0400

Hi Chris,

Alex is right:  no order should be assumed.  See, for example, the note
explicitly stating this in the last sentence of Section 3.1.  This lack of
constraint on cert order should be assumed to apply in all similar fields
(e.g., caPubs).  I guess I didn't think this needed to be repeated
throughout the document because people would already be familiar with this
practice from S/MIME (CMS) and elsewhere.

Carlisle.

> ----------
> From: 	Alex Deacon[SMTP:[email-masked]]
> Sent: 	Wednesday, April 19, 2000 2:05 PM
> To: 	'Christopher Williams'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> From: Christopher Williams [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
> 

From: Alex Deacon <[email-masked]>
To: "'Christopher Williams'" <[email-masked]>, PKIX Mailing List <[email-masked]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 11:05:17 -0700

I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

Date: Wed, 19 Apr 2000 15:15:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: Missing Protocol ?

Peter,

<snip>

> - NOTHING is added to the protocol.
>   The request is 'validate public key certificate':
>  'Tell me why you think this cert is good'.

This NOT the question. 

>   Please explain why you think you ask for something else?

You give a certificate reference and you would ONLY like to know
some (or all) the registration information that was provided at the
time of registration.

<snip>

> Are you asking for a service that send the document or the signatures
> to a server, and depending on the signature, the server returns
> some information about it:
> 
> "Please tell me what you think about these signature and provide as
>  much information as you may want to give me."

No. See the question above.

> I can't resist: 'vsd' in dvcs is one vehicle to ask this question.

I can't resist either: DVCS is NOT the right vehicule for this.

Regards,

Denis

From: Peter Sylvester <[email-masked]>
Date: Wed, 19 Apr 2000 14:11:35 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Missing Protocol ?
Cc: [email-masked]

> Bob,
> 
> I appreciate you sense of humour, at the very end of this E-mail,
> when you say: "But afer all, isn't what DIRECTORIES are for? Why do
> we need a new protocol??? The answer is LDAP.  What was the
> question??

The purpose of a directory is to provide information,
and it is explicitely tolerated that the information can be slightly
wrong and inaccurate. 

> 
> Before discussing the technical solution(s), the thread is
> discussing very validly the purpose and the goal of that (missing ?)
> protocol. Since the information that might be released will not
> match exactly with the arguments from the request (i.e. you cannot
> ask specically for an attribute) I am not convinced that LDAP would
> be the best choice. In addition, up to now, RAs do not need to
> support a Directory or structure the information they have so that
> it can be placed in a Directory.

That's not the real point: You seem to want a possibility to access
to a remote service that is akind of RA archive. The answers from this
service will be used by some RP (a juge). The answers are statements
that itsself need to be verifiable (using a signature), and re-verfiable
in case the process is reviewed. 

> 
> The other arguments you raise in your E-mail, as well as the
> examples provided by Robert Moskowitz, illustrate the topic very
> well.
> 
> Peter Sylvester while advocating for the use of DVCS was saying: "
> Since my current favorite is dvcs, I start with this: The request
> would be a for a 'verify public key certificate'. The response would
> not contain the certificate chain, or maybe it would, it can contain
> all kinds of certificates, etc, just ONE of the certEtcToken
> elements would be the signedData object created by the RA ".
> 
> The request we need has nothing to do with 'verify public key
> certificate'. DVCS is already embrassing too many purposes. It would
> not be a good idea to add one more purpose in the same shell.

- NOTHING is added to the protocol. 
  The request is 'validate public key certificate': 
 'Tell me why you think this cert is good'. 
  Please explain why you think you ask for something else?

  The distinction of what is expected to be returned and 
  what is returned is made in an application context of both
  the requester and the responder. 

- What purpose do you think is 'too much'? You can also say:
  TCP is too complicated because you can do too many things
  with it, or HTTP is too generic, you can too many things with it,
  and to many protocols are encapsulated in http, or email is
  embracing too many applications, or S/MIME is embracing too
  many features, or cmp/cmc are too big, etc.  
  The purpose of horizontal protocol layer is to become usable
  by many applications. 

> 
> Note that the request is mainly intended to be used by adjudicators
> or plaintiffs, but nothing prevents anyone to send a request.
Sometimes there are means to address denial of service attacks.

> However, a server may well refuse to provide a response. So any RP
> could make a request. It will always be up to the RA to decide
> which, if any, information will be released.
Is this different from any other cleint/server protocol that uses
some sort of authentication/authorisation mecanism? 

> 
> Let us now add a refinment about the construct of the request.
You are not going to add too many purposes I hope :-)

> Information may be released (or not) depending upon not only who the
> requestor is, but also depending upon what kind of information is
> provided. For example, if I can prove that a document was both
> signed by myself and another party, I could perhaps legitimately ask
> more information about that other party. Providing this "proof" as
> part of the (authenticated) request might be valuable. Note that
> this can be done without providing the actual content of what was
> signed, thus respecting some privacy.

Are you asking for a service that send the document or the signatures
to a server, and depending on the signature, the server returns
some information about it: 

"Please tell me what you think about these signature and provide as
 much information as you may want to give me."

I can't resist: 'vsd' in dvcs is one vehicle to ask this question.

Anyway, you are not making a refinement but asking for two
different context:

- In the first case, a judge wants to obtain from the
  RA the whole set of justifications to be used to issue a certificate.
  The RA does not make any judgement about WHY this information is
  requested, independant of the certificate usage in an actual signature.

- In the second case, the requester presents an actual usage of 
  one or more certs, i.e., a signed document. I 

Thus, you are already through 3/4 of the dvcs features to request and
obtain secrity statement about documents and certificates/assertions.
(I assume that you accept the usefulness of timestamping).

Your example is not well-chosen, I can sign all kinds of documents,
and this doesn't per-se give me the right to get information about
other entities. You might have a case on countersignatures upon
a document that you have signed first, and you want to know who
has actually 'accepted' counter-signed your data. Anyway, this
is application dependant, and not a part of the infrastructure
protocol.
 
Have fun
Peter Sylvester

Date: Wed, 19 Apr 2000 11:48:08 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: Missing Protocol ?

Bob,

I appreciate you sense of humour, at the very end of this E-mail,
when you say: "But afer all, isn't what DIRECTORIES are for? Why do
we need a new protocol??? The answer is LDAP.  What was the
question??

Before discussing the technical solution(s), the thread is
discussing very validly the purpose and the goal of that (missing ?)
protocol. Since the information that might be released will not
match exactly with the arguments from the request (i.e. you cannot
ask specically for an attribute) I am not convinced that LDAP would
be the best choice. In addition, up to now, RAs do not need to
support a Directory or structure the information they have so that
it can be placed in a Directory.

The other arguments you raise in your E-mail, as well as the
examples provided by Robert Moskowitz, illustrate the topic very
well.

Peter Sylvester while advocating for the use of DVCS was saying: "
Since my current favorite is dvcs, I start with this: The request
would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain
all kinds of certificates, etc, just ONE of the certEtcToken
elements would be the signedData object created by the RA ".

The request we need has nothing to do with 'verify public key
certificate'. DVCS is already embrassing too many purposes. It would
not be a good idea to add one more purpose in the same shell.

Note that the request is mainly intended to be used by adjudicators
or plaintiffs, but nothing prevents anyone to send a request.
However, a server may well refuse to provide a response. So any RP
could make a request. It will always be up to the RA to decide
which, if any, information will be released.

Let us now add a refinment about the construct of the request.
Information may be released (or not) depending upon not only who the
requestor is, but also depending upon what kind of information is
provided. For example, if I can prove that a document was both
signed by myself and another party, I could perhaps legitimately ask
more information about that other party. Providing this "proof" as
part of the (authenticated) request might be valuable. Note that
this can be done without providing the actual content of what was
signed, thus respecting some privacy.
 
Regards,

Denis

> Tom,
> 
> You're right, the potential sticking point is the privacy issue.
> 
> But privacy comes in several flavors, and there is also some
> concern for cluttering up certificate with information that may
> not always be required.
> 
> I don't think we need to come to the complexity of a German wine
> label (auslese cabinette, green capsule, with silver stripes) to solve this.
> 
> Consider the telephone company's policy.  My number can be listed,
> unpublished, or unlisted.  If it is listed, I may or may not list an address,
> and if I do it doesn't have to be my real address -- it could be a forwarding
> service, or just a ZIP code.  (In the LA area, it costs extra to have your
> phone be unlisted, but it costs nothing to have a phony  address. So
> hundreds of people just list their names as Joe Doakes, 90210.
> 
> If my listing it is merely unpublished, you can ask for it.
> 
> If it is unlisted, only law enforcement, and maybe other emergency
> services can get it, but I don't know if it requires a warrant in that case.
> 
> Same with the Tom Smith-with-the-beard.  Tom may not choose to list his
> hirsuteness or glabrousness, but he probably would have no problem with
> telling anyone who asks.
> 
> His social security number might be a different story, but even then
> he is unlikely to defend that to the death, as too many people already
> have access to it. But he might require that such usage be audited, and
> that he have the right to know who asked for it, just as credit checks
> must be reported upon request.
> 
> If he is under the Witness Protection program, he is going to strenuously
> resist giving anyone his real name, birth date, etc.
> 
> But afer all, isn't what DIRECTORIES are for?
> 
> Why do we need a new protocol???
> 
> The answer is LDAP.  What was the question??
> 
> Bob
> 
> >>> <[email-masked]> 04/17/00 10:25AM >>>
>      Some comments.  I think we can get a lot of this into certificates or
> CMP responses, if we don't try for a "universal solution".  If liability is
> at issue, even one of the ID's should do the trick.  The only problem I see
> is a privacy problem.  If something shouldn't be in a certificate, which
> RP's should be allowed to get it?  If ordinary unprivileged RP's are
> allowed to get it, why (other than certificate lifetime considerations)
> shouldn't it be in the certificate?
> 
>           Tom Gindin
> 
> Al Arsenault <[email-masked]> on 04/17/2000 11:19:08 AM
> 
> To:   Denis Pinkas <[email-masked]>
> cc:   ietf-pkix <[email-masked]>
> Subject:  Re: Missing Protocol ?
> 
> Now that I understand better what you're getting at with this stuff  :-)
> 
> Denis Pinkas wrote:
> >
> > Since I launched this thread, I am following the various exchanges.
> > I pick this one to comment.
> >
> > > Thierry,
> > >
> > >         I'm not sure that there is a solution for this problem that
> doesn't
> > > involve knowledge external to the PKI.
> >
> > Since the knowledge is not external to PKI, the problem may be
> > considered by the PKIX WG.
> >
> > >         Suppose that the fondest dreams of the early X.500 designers
> had come
> > > true, and every item (to include person) in the known universe had a
> > > globally unique name.  Even in that case, if you are working with one
> > > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
> need
> > > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > > out-of-band what his globally-unique name is, or at least enough
> > > disambiguating information to let you accurately pick it out from the
> > > entries in the global directory.  Otherwise, you'll never know which is
> > > which.
> > >
> > >         The same type of information can be passed to you "out-of-band"
> in the
> > > current situation; when you first begin working with the right "Jim
> > > Jones of GM", he can provide you his certificate directly, or give you
> > > enough disambiguating information to make sure you find it somewhere
> > > else.  If he doesn't, you're not going to work securely.
> > >
> > >         (All of this is a long way of saying that we're really
> wandering here.
> > > I'm not convinced that it is possible to define a technical - by which
> I
> > > mean "machine-processable" - protocol that is guaranteed to find you
> the
> > > right certificate if you don't have enough information from other
> > > contexts.)
> >
> > When dealing with signatures, it is the other way around. You have a
> > certificate, that may even contain a pseudonym. When it does not
> > contain a pseudonym, the question is still: who indeed is that
> > person (e.g. Jim Jones 22) ? This person may be liable for a
> > contract worth 10.000 $ and the requester would like to get the home
> > address of the signer.
> >
> > The information that was obtained at the time of registration (and
> > that is NOT contained in the certificate) may help.
> >
> > The problem is that this registration information varies from one CA
> > to another and we are not going to standardize it easily. Is it
> > really a problem ?
> >
> > We could standardize the request and very loosely standardize the
> > response. The request is easy to standardize: "I want more
> > registration information on the certificate holder that has the
> > following serial number". Depending both, on who the requester is
> > and the certificate policy of the CA, more or less (even none)
> > information will be released to the requester. We could thus
> > standardize the response without mandating any component to be
> > returned. In any case, it would be better than paper.
> >
> > Thoughts ?
> >
> > Denis
> >
> >
> >
> 
> More "questions" than "thoughts":
> 
> 1.  Is the set of information that might reasonably be requested
> sufficiently bounded as to be specifiable in a protocol?  Off the top of
> my head, depending on the circumstances, I might ask for:
> 
>      - passport number/nationality
>      - employee ID number
>      - mail stop/address
>      - phone number
>      - driver's license number
>      - SSN/other identity number
>      - physically descriptive information (no, I'm not kidding here.  I
> used to have a roommate named Tom Smith.  He worked in an office with
> another Tom Smith.  The middle names and even the generational qualifier
> were the same.  So when you called, you asked for 'the Tom Smith with a
> beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
> The guy with the beard was threatened with mayhem if he ever shaved while
> working in that office.:-)
>      - a whole bunch of other stuff
> 
> [Tom Gindin] Most of your list, up to (not including) physically
> descriptive information, has perfectly well-defined formats in our domain
> already - and IMO we should start with those.  The ones I have been trying
> to profile for an OTHER-NAME format to go into certificates are Employee ID
> number, SSN or other nationwide government ID number, CA-assigned ID
> number, and Passport, Driver's license, or other government agency ID
> number.  Maybe we should include phone number (distinguished between work
> and home) as long as there's a separate place for extension number at work.
> How would we do mail stop/address - perhaps with an X.400 Physical Delivery
> Address?  Of course, most people have different work and home mail
> addresses too.
> 
> If this is going to be meaningful to software and hardware, we'll have to
> quantify/limit the list of acceptable information somehow.
> 
> [Tom Gindin] Yes, we need to keep the list down.  However, I don't think
> that means empty.  For the four ID types, I have only three syntaxes and
> two of them are effectively subsets of the other.
> 
> 2.  Do you envision the response being anything that a machine might
> parse and act upon, or only a general form for returning information for
> human consumption/decision?
> 
> 3.  If we can get past 1., do you picture this being a new protocol, or an
> extension to CMP/CMC?
> 
> Thanks,
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> (410) 480-2052

From: =?ks_c_5601-1987?B?waS8urHV?= <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Wed, 19 Apr 2000 13:29:39 +0900
Importance: Normal

auth 99220e68 subscribe ietf-pkix \
=?ks_c_5601-1987?B?waS8urHV?= <[email-masked]>

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: What is the order of certificates in a certificate chain?
Date: Tue, 18 Apr 2000 16:41:02 +0100

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: thisMessage POP (again) - spec is contradictory
Date: Tue, 18 Apr 2000 16:36:16 +0100

Sorry to bring this up again, but the spec is still muddled on this issue.

RFC2510bis, section 3.28 says:

"...proof of possession of the private decryption key may be demonstrated
   in one of three ways.

      1) By the inclusion of the private key (encrypted) in the
         CertRequest (in the PKIArchiveOptions control structure)."

This suggests that POP is implicit, because the EE is asking the CA to
archive the private key and providing the private key in an ArchiveOptions
control.  The CA can decrypt the private key in the ArchiveOptions control
and match it against the public key in the CertTemplate.

Appendix D then says:

"POPOPrivKey ::= CHOICE {
    thisMessage       [0] BIT STRING,
-- **********
-- * the type of "thisMessage" was mistakenly given as BIT STRING in
-- * RFC 2511; it should have been "EncryptedValue" (in accordance with
-- * Section 3.2.2 of this specification).  Therefore, this document makes
-- * the behavioral clarification of specifying that the contents of
-- * "thisMessage" MUST be encoded as an EncryptedValue and then wrapped
-- * in a BIT STRING.  This allows the necessary conveyance and protection
-- * of the private key while maintaining bits-on-the-wire compatibility
-- * with RFC 2511.
-- **********
    subsequentMessage [1] SubsequentMessage,
    dhMAC             [2] BIT STRING }"

These instructions are not compatible:

1. They tell you to do two different things - stick the private key in an
ArchiveOptions control OR in an EncryptedValue.
2. If the certificate request contains an ArchiveOptions control, the
contents of the thisMessage BIT STRING are redundant.

The implicit POP is somewhat more elegant.  Encoding an EncryptedValue as a
BIT STRING is a bit of a kludge.

The contradicitory instructions can be reconciled as follows:
If an ArchiveOptions control is included in the certificate request,
implicit POP MAY be indicated by setting thisMessage to an empty BIT STRING.
If thisMessage is empty, an ArchiveOptions control MUST be included in the
certificate request.

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Peter Sylvester <[email-masked]>
Date: Tue, 18 Apr 2000 15:30:47 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Missing Protocol ?
Cc: [email-masked], [email-masked]

> 
>      Some comments.  I think we can get a lot of this into certificates or
> CMP responses, if we don't try for a "universal solution".  If liability is
> at issue, even one of the ID's should do the trick.  The only problem I see
> is a privacy problem.  If something shouldn't be in a certificate, which
> RP's should be allowed to get it?  If ordinary unprivileged RP's are
> allowed to get it, why (other than certificate lifetime considerations)
> shouldn't it be in the certificate?
> 
'Ordinary' i.e., non-authorised RPs are NOT allowed to access to such data.

From: Peter Sylvester <[email-masked]>
Date: Tue, 18 Apr 2000 13:46:31 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Missing Protocol ?
Cc: [email-masked]

> 
> Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.
> 
> This fits well within perceived uses of the genm and genp of CMP.  If it is 
> a request from Jon Q, the CA can decide what to respond.  If genm contains 
> a warrant, well then...
> 

- An RA collects the justifications and at the moment when it demands the certificate,
  it creates a time stamped document containing the data in whatever way and stores it
  wherever this should be, indexed by one or all the certificates it is related to.
  The document may even contain the certificates. 

- An authorised RP may asks someone (else) to return this document. The
  server should return a statement saying that 'the RA had used the data xxx to
  issue the certificate, or in other words: The server decides that the cert is/was
  valid because of of the existence of that document content.  

There are obviously several ways to implement this with some of the protocols
that exist. Since my current favorite is dvcs, I start with this:

The request would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain all kinds
of certificates, etc, just ONE of the certEtcToken elements would be the
signedData object created by the RA. 

CMP or CMC are similar good candidates. 

Peter Sylvester

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Original PKI message general info / Nested message message body
Date: Tue, 18 Apr 2000 12:25:40 +0100

RFC 2510bis adds the OrigPKIMessage general info type which allows an
intermediate party (an RA presumably) to embed a message from the EE within
the header of a second message from the RA; the CA can then recover the
original message.  This appears to fulfill exactly the same function as the
nested message PKIBody type.  One of these appears to be redundant; which
one?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

Date: Mon, 17 Apr 2000 14:49:45 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Missing Protocol ?

Tom,

You're right, the potential sticking point is the privacy issue.

But privacy comes in several flavors, and there is also some 
concern for cluttering up certificate with information that may 
not always be required.

I don't think we need to come to the complexity of a German wine 
label (auslese cabinette, green capsule, with silver stripes) to solve this.

Consider the telephone company's policy.  My number can be listed, 
unpublished, or unlisted.  If it is listed, I may or may not list an address,
and if I do it doesn't have to be my real address -- it could be a forwarding 
service, or just a ZIP code.  (In the LA area, it costs extra to have your 
phone be unlisted, but it costs nothing to have a phony  address. So 
hundreds of people just list their names as Joe Doakes, 90210.

If my listing it is merely unpublished, you can ask for it. 

If it is unlisted, only law enforcement, and maybe other emergency 
services can get it, but I don't know if it requires a warrant in that case.

Same with the Tom Smith-with-the-beard.  Tom may not choose to list his 
hirsuteness or glabrousness, but he probably would have no problem with 
telling anyone who asks.  

His social security number might be a different story, but even then 
he is unlikely to defend that to the death, as too many people already 
have access to it. But he might require that such usage be audited, and 
that he have the right to know who asked for it, just as credit checks 
must be reported upon request.

If he is under the Witness Protection program, he is going to strenuously 
resist giving anyone his real name, birth date, etc.

But afer all, isn't what DIRECTORIES are for?

Why do we need a new protocol???

The answer is LDAP.  What was the question??

Bob

>>> <[email-masked]> 04/17/00 10:25AM >>>
     Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <[email-masked]> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <[email-masked]>
cc:   ietf-pkix <[email-masked]>
Subject:  Re: Missing Protocol ?

Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that
doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> >         Suppose that the fondest dreams of the early X.500 designers
had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band"
in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really
wandering here.
> > I'm not convinced that it is possible to define a technical - by which
I
> > mean "machine-processable" - protocol that is guaranteed to find you
the
> > right certificate if you don't have enough information from other
> > contexts.)
>
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
>
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
>
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
>
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
>
> Thoughts ?
>
> Denis
>
>
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

     - passport number/nationality
     - employee ID number
     - mail stop/address
     - phone number
     - driver's license number
     - SSN/other identity number
     - physically descriptive information (no, I'm not kidding here.  I
used to have a roommate named Tom Smith.  He worked in an office with
another Tom Smith.  The middle names and even the generational qualifier
were the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
The guy with the beard was threatened with mayhem if he ever shaved while
working in that office.:-)
     - a whole bunch of other stuff

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

If this is going to be meaningful to software and hardware, we'll have to
quantify/limit the list of acceptable information somehow.

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or an
extension to CMP/CMC?

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

From: [email-masked]
To: Al Arsenault <[email-masked]>
cc: Denis Pinkas <[email-masked]>, ietf-pkix <[email-masked]>
Date: Mon, 17 Apr 2000 12:25:09 -0400
Subject: Re: Missing Protocol ?

     Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <[email-masked]> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <[email-masked]>
cc:   ietf-pkix <[email-masked]>
Subject:  Re: Missing Protocol ?

Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that
doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> >         Suppose that the fondest dreams of the early X.500 designers
had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band"
in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really
wandering here.
> > I'm not convinced that it is possible to define a technical - by which
I
> > mean "machine-processable" - protocol that is guaranteed to find you
the
> > right certificate if you don't have enough information from other
> > contexts.)
>
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
>
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
>
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
>
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
>
> Thoughts ?
>
> Denis
>
>
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

     - passport number/nationality
     - employee ID number
     - mail stop/address
     - phone number
     - driver's license number
     - SSN/other identity number
     - physically descriptive information (no, I'm not kidding here.  I
used to have a roommate named Tom Smith.  He worked in an office with
another Tom Smith.  The middle names and even the generational qualifier
were the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
The guy with the beard was threatened with mayhem if he ever shaved while
working in that office.:-)
     - a whole bunch of other stuff

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

If this is going to be meaningful to software and hardware, we'll have to
quantify/limit the list of acceptable information somehow.

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or an
extension to CMP/CMC?

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

Date: Mon, 17 Apr 2000 12:43:01 -0400
To: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: Missing Protocol ?
Cc: ietf-pkix <[email-masked]>

At 05:01 PM 4/17/2000 +0200, Denis Pinkas wrote:

>We could standardize the request and very loosely standardize the
>response. The request is easy to standardize: "I want more
>registration information on the certificate holder that has the
>following serial number". Depending both, on who the requester is
>and the certificate policy of the CA, more or less (even none)
>information will be released to the requester. We could thus
>standardize the response without mandating any component to be
>returned. In any case, it would be better than paper.

Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.

This fits well within perceived uses of the genm and genp of CMP.  If it is 
a request from Jon Q, the CA can decide what to respond.  If genm contains 
a warrant, well then...

We have the basics here to build up requests for archived data.

I have been talking to some US university people that want anonymous certs 
for their library system.  A student might use their student cert for such 
a library cert.  A resident might use their DMV cert to get one.

But what if a proper authority needed to know who is cert holder 
3458923?  If the requester was the librarian, the response might be:  "A 
resident (non-student) of the State".  If it was a  law-type with a warrant 
it might be "Student ID-3456"; then let them deal with the school admin to 
learn more....

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Mon, 17 Apr 2000 17:57:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Al Arsenault <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: Missing Protocol ?

> Now that I understand better what you're getting at with this stuff  :-)
> 
> Denis Pinkas wrote:
> >
> > Since I launched this thread, I am following the various exchanges.
> > I pick this one to comment.
> >
> > > Thierry,
> > >
> > >         I'm not sure that there is a solution for this problem that doesn't
> > > involve knowledge external to the PKI.
> >
> > Since the knowledge is not external to PKI, the problem may be
> > considered by the PKIX WG.
> >
> > >         Suppose that the fondest dreams of the early X.500 designers had come
> > > true, and every item (to include person) in the known universe had a
> > > globally unique name.  Even in that case, if you are working with one
> > > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> > > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > > out-of-band what his globally-unique name is, or at least enough
> > > disambiguating information to let you accurately pick it out from the
> > > entries in the global directory.  Otherwise, you'll never know which is
> > > which.
> > >
> > >         The same type of information can be passed to you "out-of-band" in the
> > > current situation; when you first begin working with the right "Jim
> > > Jones of GM", he can provide you his certificate directly, or give you
> > > enough disambiguating information to make sure you find it somewhere
> > > else.  If he doesn't, you're not going to work securely.
> > >
> > >         (All of this is a long way of saying that we're really wandering here.
> > > I'm not convinced that it is possible to define a technical - by which I
> > > mean "machine-processable" - protocol that is guaranteed to find you the
> > > right certificate if you don't have enough information from other
> > > contexts.)
> >
> > When dealing with signatures, it is the other way around. You have a
> > certificate, that may even contain a pseudonym. When it does not
> > contain a pseudonym, the question is still: who indeed is that
> > person (e.g. Jim Jones 22) ? This person may be liable for a
> > contract worth 10.000 $ and the requester would like to get the home
> > address of the signer.
> >
> > The information that was obtained at the time of registration (and
> > that is NOT contained in the certificate) may help.
> >
> > The problem is that this registration information varies from one CA
> > to another and we are not going to standardize it easily. Is it
> > really a problem ?
> >
> > We could standardize the request and very loosely standardize the
> > response. The request is easy to standardize: "I want more
> > registration information on the certificate holder that has the
> > following serial number". Depending both, on who the requester is
> > and the certificate policy of the CA, more or less (even none)
> > information will be released to the requester. We could thus
> > standardize the response without mandating any component to be
> > returned. In any case, it would be better than paper.
> >
> > Thoughts ?
> >
> > Denis
> >
> >
> >
> 
> More "questions" than "thoughts":
> 
> 1.  Is the set of information that might reasonably be requested
> sufficiently bounded as to be specifiable in a protocol?  Off the top of
> my head, depending on the circumstances, I might ask for:
> 
>         - passport number/nationality
>         - employee ID number
>         - mail stop/address
>         - phone number
>         - driver's license number
>         - SSN/other identity number
>         - physically descriptive information (no, I'm not kidding here.  

I am not sure that you *directly* ask for this. This is what you may
*receive*. The request would use some category of information. It
would be up to the RA/CA to return whatever information matches with
these categories.

> I used
> to have a roommate named Tom Smith.  He worked in an office with another
> Tom Smith.  The middle names and even the generational qualifier were
> the same.  So when you called, you asked for 'the Tom Smith with a
> beard' or 'the clean-shaven Tom Smith', depending on which one you
> wanted. The guy with the beard was threatened with mayhem if he ever
> shaved while working in that office.:-)
>         - a whole bunch of other stuff
> 
> If this is going to be meaningful to software and hardware, we'll have
> to quantify/limit the list of acceptable information somehow.

The request may be sent by a computer, e.g. acting on behalf of a
person. The response might need to be read by a human being to be
understable.

> 2.  Do you envision the response being anything that a machine might
> parse and act upon, or only a general form for returning information for
> human consumption/decision?

The later.

> 3.  If we can get past 1., do you picture this being a new protocol, or
> an extension to CMP/CMC?

I have no preference at all, ... as long as we have that protocol.

Regards,

Denis

> 
> Thanks,
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> (410) 480-2052

Date: Mon, 17 Apr 2000 11:19:08 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Denis Pinkas <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Missing Protocol ?

Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
> 
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
> 
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that doesn't
> > involve knowledge external to the PKI.
> 
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
> 
> >         Suppose that the fondest dreams of the early X.500 designers had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band" in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really wandering here.
> > I'm not convinced that it is possible to define a technical - by which I
> > mean "machine-processable" - protocol that is guaranteed to find you the
> > right certificate if you don't have enough information from other
> > contexts.)
> 
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
> 
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
> 
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
> 
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
> 
> Thoughts ?
> 
> Denis
> 
> 
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

	- passport number/nationality
	- employee ID number
	- mail stop/address
	- phone number
	- driver's license number
	- SSN/other identity number
	- physically descriptive information (no, I'm not kidding here.  I used
to have a roommate named Tom Smith.  He worked in an office with another
Tom Smith.  The middle names and even the generational qualifier were
the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you
wanted. The guy with the beard was threatened with mayhem if he ever
shaved while working in that office.:-)
	- a whole bunch of other stuff

If this is going to be meaningful to software and hardware, we'll have
to quantify/limit the list of acceptable information somehow.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or
an extension to CMP/CMC?

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

Date: Mon, 17 Apr 2000 17:01:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Al Arsenault <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Missing Protocol ?

Since I launched this thread, I am following the various exchanges.
I pick this one to comment.

> Thierry,
> 
>         I'm not sure that there is a solution for this problem that doesn't
> involve knowledge external to the PKI.

Since the knowledge is not external to PKI, the problem may be
considered by the PKIX WG. 

>         Suppose that the fondest dreams of the early X.500 designers had come
> true, and every item (to include person) in the known universe had a
> globally unique name.  Even in that case, if you are working with one
> "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> out-of-band what his globally-unique name is, or at least enough
> disambiguating information to let you accurately pick it out from the
> entries in the global directory.  Otherwise, you'll never know which is
> which.
> 
>         The same type of information can be passed to you "out-of-band" in the
> current situation; when you first begin working with the right "Jim
> Jones of GM", he can provide you his certificate directly, or give you
> enough disambiguating information to make sure you find it somewhere
> else.  If he doesn't, you're not going to work securely.
> 
>         (All of this is a long way of saying that we're really wandering here.
> I'm not convinced that it is possible to define a technical - by which I
> mean "machine-processable" - protocol that is guaranteed to find you the
> right certificate if you don't have enough information from other
> contexts.)

When dealing with signatures, it is the other way around. You have a
certificate, that may even contain a pseudonym. When it does not
contain a pseudonym, the question is still: who indeed is that
person (e.g. Jim Jones 22) ? This person may be liable for a
contract worth 10.000 $ and the requester would like to get the home
address of the signer.

The information that was obtained at the time of registration (and
that is NOT contained in the certificate) may help.

The problem is that this registration information varies from one CA
to another and we are not going to standardize it easily. Is it
really a problem ? 

We could standardize the request and very loosely standardize the
response. The request is easy to standardize: "I want more
registration information on the certificate holder that has the
following serial number". Depending both, on who the requester is
and the certificate policy of the CA, more or less (even none)
information will be released to the requester. We could thus
standardize the response without mandating any component to be
returned. In any case, it would be better than paper.

Thoughts ?

Denis

> 
> 
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> (410) 480-2052
> 
> Thierry Van Doninck wrote:
> >
> > Roger,
> >
> > Yes,
> >
> > But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
> > Therefor a relying party might not know wether the certified party can be allowed to perform a certain
> > action. A certificate received by a RP might not contain sufficient information to authenticate
> > the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)
> >
> > I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ),
> > but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)
> >
> > Thierry Van Doninck
> > eMail : [email-masked]
> >
> > ryounglove%lucent.com@Internet
> > 14/04/2000 21:14
> > To:     egerck%nma.com@Internet
> > cc:     ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)
> >
> > Subject:        Re: Missing Protocol ?
> >
> > I agree with both Dave and Ed, however I do not believe that a new WG is
> > needed. The individual identity (carbon or silicon life form) that is
> > certified with a digital certificate is the responsibility of the PKI which
> > is issuing the cert. The Certificate Policy written by that PKI operator
> > supplies the requirements for identification authentication. The CA CPS
> > states how the CP requirements are met. It is the Relying Parties
> > responsibility to properly evaluate the validity of a certificate that they
> > receive. When both the CP OID and the CPS OID is included in the cert it
> > becomes easy to evaluate the validity.
> > At 01:41 PM 4/14/2000 , you wrote:
> > >Dave:
> > >
> > >Yes and to your final paragraph.  A new WG would be needed -- otherwise
> > >this WG would need to backtrack so much that nothing would be left ;-)
> > >OTOH, with a new WG then what this WG has done might be a *component*
> > >in a bigger frame, and a useful one.
> > >
> > >Cheers,
> > >
> > >Ed Gerck
> > >
> > >"David P. Kemp" wrote:
> > >
> > > > > From: Denis Pinkas <[email-masked]>
> > > > > > From: Ed Gerck
> > > > > > Here, in PKIX, the main purpose of a CA is also to bind a public
> > > key to the name
> > > > > > contained in the certificate and thus assure third parties that
> > > some measure of care
> > > > > > was taken to ensure that this binding is valid for both -- i.e.,
> > > name and key. However,
> > > > > > the issue whether a user's DN actually corresponds to identity
> > > credentials that are
> > > > > > *globally* linked to a person, or to a local alias or, simply to an
> > > e-mail address -- and
> > > > > > how such association was verified --   is  outside the scope of
> > > PKIX and depends
> > > > > > on each CA's CPS.
> > > > >
> > > > > I am not sure that this is really outside the scope of PKIX. If some
> > > > > judge would like to make the difference between John Smith 22 and
> > > > > John Smith 23, what can he do ? Nothing that has been standardized
> > > > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > > > should ? What kind of solution ? Being able to get back (when
> > > > > appropriate) the registration information (sometimes called the
> > > > > credentials) that has been registered at the time of registration by
> > > > > the RA. I do not think that it may be practical to get that
> > > > > information by paper and in a different format for every CA in the
> > > > > world. A protocol (and a schema) might be useful.
> > > > >
> > > > > Denis
> > > >
> > > > Denis,
> > > >
> > > > As long as CPSs are different, the "big identity in the sky" (the
> > > > information about a subject which makes John Smith 22 different from
> > > > John Smith 23) will be different, and outside the scope of PKIX.  If
> > > > the judge has access to a certain body of information:  employment and
> > > > credit history, property ownership and tax records, utility bills, etc,
> > > > and the CA has used any of that information to establish identity, then
> > > > the certificate may be useful to the judge.  If the CA uses only email
> > > > address to establish "identity", the certificate will be useless to a
> > > > judge dealing in non-electronic matters.  I don't see how PKIX could
> > > > consider in-scope an effort to develop a schema for the universe
> > > > of information which could constitute a human identity.
> > > >
> > > > Dave
> >
> > ---
> > TTFN
> > Roger W. Younglove, CISSP
> > Sr. Network Security Consultant
> > NetworkCare® Security Services
> > 100 Galleria Officentre, Ste. 200
> > Southfield, MI 48034
> > Numeric page: 888.935.6755
> > E-mail page:
> > [email-masked]
> > eFax number: 413.425.5368
> > www.lucent.com/netcare

Date: Mon, 17 Apr 2000 09:26:52 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Thierry Van Doninck <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Missing Protocol ?

Thierry,

	I'm not sure that there is a solution for this problem that doesn't
involve knowledge external to the PKI. 

	Suppose that the fondest dreams of the early X.500 designers had come
true, and every item (to include person) in the known universe had a
globally unique name.  Even in that case, if you are working with one
"Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
to distinguish them, then YOUR "Jim Jones of GM" has to tell you
out-of-band what his globally-unique name is, or at least enough
disambiguating information to let you accurately pick it out from the
entries in the global directory.  Otherwise, you'll never know which is
which.

	The same type of information can be passed to you "out-of-band" in the
current situation; when you first begin working with the right "Jim
Jones of GM", he can provide you his certificate directly, or give you
enough disambiguating information to make sure you find it somewhere
else.  If he doesn't, you're not going to work securely.  

	(All of this is a long way of saying that we're really wandering here. 
I'm not convinced that it is possible to define a technical - by which I
mean "machine-processable" - protocol that is guaranteed to find you the
right certificate if you don't have enough information from other
contexts.)

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

Thierry Van Doninck wrote:
> 
> Roger,
> 
> Yes,
> 
> But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
> Therefor a relying party might not know wether the certified party can be allowed to perform a certain
> action. A certificate received by a RP might not contain sufficient information to authenticate
> the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)
> 
> I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ),
> but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)
> 
> Thierry Van Doninck
> eMail : [email-masked]
> 
> ryounglove%lucent.com@Internet
> 14/04/2000 21:14
> To:     egerck%nma.com@Internet
> cc:     ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)
> 
> Subject:        Re: Missing Protocol ?
> 
> I agree with both Dave and Ed, however I do not believe that a new WG is
> needed. The individual identity (carbon or silicon life form) that is
> certified with a digital certificate is the responsibility of the PKI which
> is issuing the cert. The Certificate Policy written by that PKI operator
> supplies the requirements for identification authentication. The CA CPS
> states how the CP requirements are met. It is the Relying Parties
> responsibility to properly evaluate the validity of a certificate that they
> receive. When both the CP OID and the CPS OID is included in the cert it
> becomes easy to evaluate the validity.
> At 01:41 PM 4/14/2000 , you wrote:
> >Dave:
> >
> >Yes and to your final paragraph.  A new WG would be needed -- otherwise
> >this WG would need to backtrack so much that nothing would be left ;-)
> >OTOH, with a new WG then what this WG has done might be a *component*
> >in a bigger frame, and a useful one.
> >
> >Cheers,
> >
> >Ed Gerck
> >
> >"David P. Kemp" wrote:
> >
> > > > From: Denis Pinkas <[email-masked]>
> > > > > From: Ed Gerck
> > > > > Here, in PKIX, the main purpose of a CA is also to bind a public
> > key to the name
> > > > > contained in the certificate and thus assure third parties that
> > some measure of care
> > > > > was taken to ensure that this binding is valid for both -- i.e.,
> > name and key. However,
> > > > > the issue whether a user's DN actually corresponds to identity
> > credentials that are
> > > > > *globally* linked to a person, or to a local alias or, simply to an
> > e-mail address -- and
> > > > > how such association was verified --   is  outside the scope of
> > PKIX and depends
> > > > > on each CA's CPS.
> > > >
> > > > I am not sure that this is really outside the scope of PKIX. If some
> > > > judge would like to make the difference between John Smith 22 and
> > > > John Smith 23, what can he do ? Nothing that has been standardized
> > > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > > should ? What kind of solution ? Being able to get back (when
> > > > appropriate) the registration information (sometimes called the
> > > > credentials) that has been registered at the time of registration by
> > > > the RA. I do not think that it may be practical to get that
> > > > information by paper and in a different format for every CA in the
> > > > world. A protocol (and a schema) might be useful.
> > > >
> > > > Denis
> > >
> > > Denis,
> > >
> > > As long as CPSs are different, the "big identity in the sky" (the
> > > information about a subject which makes John Smith 22 different from
> > > John Smith 23) will be different, and outside the scope of PKIX.  If
> > > the judge has access to a certain body of information:  employment and
> > > credit history, property ownership and tax records, utility bills, etc,
> > > and the CA has used any of that information to establish identity, then
> > > the certificate may be useful to the judge.  If the CA uses only email
> > > address to establish "identity", the certificate will be useless to a
> > > judge dealing in non-electronic matters.  I don't see how PKIX could
> > > consider in-scope an effort to develop a schema for the universe
> > > of information which could constitute a human identity.
> > >
> > > Dave
> 
> ---
> TTFN
> Roger W. Younglove, CISSP
> Sr. Network Security Consultant
> NetworkCare® Security Services
> 100 Galleria Officentre, Ste. 200
> Southfield, MI 48034
> Numeric page: 888.935.6755
> E-mail page:
> [email-masked]
> eFax number: 413.425.5368
> www.lucent.com/netcare

Date: 17 Apr 2000 09:13:05 +0200
From: Thierry Van Doninck <[email-masked]>
To: ietf-pkix <[email-masked]>
Subject: Re: Missing Protocol ?

Roger,

Yes,

But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
Therefor a relying party might not know wether the certified party can be allowed to perform a certain 
action. A certificate received by a RP might not contain sufficient information to authenticate 
the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)

I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ), 
but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)

Thierry Van Doninck
eMail : [email-masked]

ryounglove%lucent.com@Internet
14/04/2000 21:14
To:	egerck%nma.com@Internet
cc:	ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)

Subject:	Re: Missing Protocol ?

I agree with both Dave and Ed, however I do not believe that a new WG is 
needed. The individual identity (carbon or silicon life form) that is 
certified with a digital certificate is the responsibility of the PKI which 
is issuing the cert. The Certificate Policy written by that PKI operator 
supplies the requirements for identification authentication. The CA CPS 
states how the CP requirements are met. It is the Relying Parties 
responsibility to properly evaluate the validity of a certificate that they 
receive. When both the CP OID and the CPS OID is included in the cert it 
becomes easy to evaluate the validity.
At 01:41 PM 4/14/2000 , you wrote:
>Dave:
>
>Yes and to your final paragraph.  A new WG would be needed -- otherwise
>this WG would need to backtrack so much that nothing would be left ;-)
>OTOH, with a new WG then what this WG has done might be a *component*
>in a bigger frame, and a useful one.
>
>Cheers,
>
>Ed Gerck
>
>"David P. Kemp" wrote:
>
> > > From: Denis Pinkas <[email-masked]>
> > > > From: Ed Gerck
> > > > Here, in PKIX, the main purpose of a CA is also to bind a public 
> key to the name
> > > > contained in the certificate and thus assure third parties that 
> some measure of care
> > > > was taken to ensure that this binding is valid for both -- i.e., 
> name and key. However,
> > > > the issue whether a user's DN actually corresponds to identity 
> credentials that are
> > > > *globally* linked to a person, or to a local alias or, simply to an 
> e-mail address -- and
> > > > how such association was verified --   is  outside the scope of 
> PKIX and depends
> > > > on each CA's CPS.
> > >
> > > I am not sure that this is really outside the scope of PKIX. If some
> > > judge would like to make the difference between John Smith 22 and
> > > John Smith 23, what can he do ? Nothing that has been standardized
> > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > should ? What kind of solution ? Being able to get back (when
> > > appropriate) the registration information (sometimes called the
> > > credentials) that has been registered at the time of registration by
> > > the RA. I do not think that it may be practical to get that
> > > information by paper and in a different format for every CA in the
> > > world. A protocol (and a schema) might be useful.
> > >
> > > Denis
> >
> > Denis,
> >
> > As long as CPSs are different, the "big identity in the sky" (the
> > information about a subject which makes John Smith 22 different from
> > John Smith 23) will be different, and outside the scope of PKIX.  If
> > the judge has access to a certain body of information:  employment and
> > credit history, property ownership and tax records, utility bills, etc,
> > and the CA has used any of that information to establish identity, then
> > the certificate may be useful to the judge.  If the CA uses only email
> > address to establish "identity", the certificate will be useless to a
> > judge dealing in non-electronic matters.  I don't see how PKIX could
> > consider in-scope an effort to develop a schema for the universe
> > of information which could constitute a human identity.
> >
> > Dave

---
TTFN
Roger W. Younglove, CISSP
Sr. Network Security Consultant
NetworkCare® Security Services
100 Galleria Officentre, Ste. 200
Southfield, MI 48034
Numeric page: 888.935.6755
E-mail page:
[email-masked]
eFax number: 413.425.5368
www.lucent.com/netcare

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: pki product report
Date: Sun, 16 Apr 2000 20:21:25 -0400

	You may wish to search the Federal Register in the United States
under notices published by the US Patent and Trademark Office in 1999. (My
apologies for not being able to be more specific as to the publication
date.) I recall they published a very interesting table comparing PKI
products in relation to a procurement "sole source" justification. 
	
	> From:	Gao Yuhang [SMTP:[email-masked]]
	> Sent:	Thursday, April 13, 2000 6:11 PM
	> To:	pki_ietf list
	> Subject:	pki product report
	> 
	> 	Please excuse for off-topic. But can anyonehelp me to find
	> reports on current PKI products,with explanations and
comparisions, such
	> as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate
Server?
	> 
	> Thanks,
	> Hazel
	>  ______________________________________________
	>   Miss Yuhang Gao
	>   Network Center, Computer Dept.
	>   Southeast University,
	>   Nanjing, Jiangsu,
	>   P.R.China
	>   210096

From: "McMahon, Piers" <[email-masked]>
To: Gao Yuhang <[email-masked]>, pki_ietf list <[email-masked]>
Subject: RE: pki product report
Date: Fri, 14 Apr 2000 23:50:54 +0100

There are a couple of reasonably up-to-date and comprehensive (but unfortunately, 
not free) reports from industry analysts.  These cover PKI business drivers, technology,
standards (including various assertions about PKIX take-up), deployment, and the specific 
commercial solutions you ask about.    For example:
  http://www.itresearch.com/alfatst4.nsf/UNITABS/W20448
  http://www.radicati.com/tocs/toc_2000pki.htm

I have seen a number of other surveys of PKI(X) implementations (whether free and/or 
commercial software) on the net, but I don't know a *recent* one.  Hopefully some list members 
may have suggestions.

If you want to do any comparisons yourself, there are also some general information sites, 
groups, frameworks, and certification programs related to PKI & conformance / interoperability 
testing.   Some of these may help you with your functional and other criteria  ... e.g.
   http://csrc.nist.gov/pki/twg/welcome.html
   http://www.opengroup.org/publications/catalog/g801.htm
   http://www.icsa.net/html/communities/pki/
   http://www.pkiforum.org/About/index.htm
  etc

> From:	Gao Yuhang [SMTP:[email-masked]]
> Sent:	Thursday, April 13, 2000 6:11 PM
> To:	pki_ietf list
> Subject:	pki product report
> 
> 	Please excuse for off-topic. But can anyonehelp me to find
> reports on current PKI products,with explanations and comparisions, such
> as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate Server?
> 
> Thanks,
> Hazel
>  ______________________________________________
>   Miss Yuhang Gao
>   Network Center, Computer Dept.
>   Southeast University,
>   Nanjing, Jiangsu,
>   P.R.China
>   210096

Date: Fri, 14 Apr 2000 16:39:46 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Missing Protocol ?
To: [email-masked]
Content-MD5: 19QHSrf6k2/V4c2P+E82DA==

Oh, well in that case, why don't we just use GeneralName:registeredID
and be done with it.

Both OIDs and DistinguishedNames are supposed to have Naming
Authorities which maintain registries and delegate the responsibility
to maintain subordinate registries.  But only OIDs seem to actually
follow the model :-(.  The only way to get an OID arc under US(840) is
to get it from ANSI.  There is no corresponding discipline in
establishing DNs beginning with, e.g., C=US, and until every cert
issuer agrees that there should be, there will be no global DNs.

Dave

> From: [email-masked]
> To: "David P. Kemp" <[email-masked]>
> cc: [email-masked]
> Date: Fri, 14 Apr 2000 16:06:03 -0400
> 
>      I don't think that anyone is proposing "an effort to develop a schema
> for the universe of information which could constitute a human identity".
> At least I hope not :-(
>      What I, at least, am proposing is a mechanism by which identifiers
> which were assigned by a known identified organization can be represented
> in a GeneralName, in such a way that an RP can tell who is the assignment
> authority for the identifier.  The cases where the assignment authority is
> a government agency or the issuing CA are of special importance.  Some may
> consider this out of scope for PKIX, but it is certainly not more complex
> or unworkable than the existing DN arrangement.
>      The fields that would actually be used in this way are likely to
> include things like employee identifications.  "John Smith who has been
> General Motors employee 356789" is a much more definitive identifier than
> "John Smith" or even "John Edward Smith from Michigan who works for GM".
> 
>           Tom Gindin

From: [email-masked]
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Date: Fri, 14 Apr 2000 16:06:03 -0400
Subject: Re: Missing Protocol ?

     I don't think that anyone is proposing "an effort to develop a schema
for the universe of information which could constitute a human identity".
At least I hope not :-(
     What I, at least, am proposing is a mechanism by which identifiers
which were assigned by a known identified organization can be represented
in a GeneralName, in such a way that an RP can tell who is the assignment
authority for the identifier.  The cases where the assignment authority is
a government agency or the issuing CA are of special importance.  Some may
consider this out of scope for PKIX, but it is certainly not more complex
or unworkable than the existing DN arrangement.
     The fields that would actually be used in this way are likely to
include things like employee identifications.  "John Smith who has been
General Motors employee 356789" is a much more definitive identifier than
"John Smith" or even "John Edward Smith from Michigan who works for GM".

          Tom Gindin

"David P. Kemp" <[email-masked]> on 04/14/2000 01:25:23 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: Missing Protocol ?

> From: Denis Pinkas <[email-masked]>
> > From: Ed Gerck
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to
the name
> > contained in the certificate and thus assure third parties that some
measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name
and key. However,
> > the issue whether a user's DN actually corresponds to identity
credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an
e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX
and depends
> > on each CA's CPS.
>
> I am not sure that this is really outside the scope of PKIX. If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.
>
> Denis

Denis,

As long as CPSs are different, the "big identity in the sky" (the
information about a subject which makes John Smith 22 different from
John Smith 23) will be different, and outside the scope of PKIX.  If
the judge has access to a certain body of information:  employment and
credit history, property ownership and tax records, utility bills, etc,
and the CA has used any of that information to establish identity, then
the certificate may be useful to the judge.  If the CA uses only email
address to establish "identity", the certificate will be useless to a
judge dealing in non-electronic matters.  I don't see how PKIX could
consider in-scope an effort to develop a schema for the universe
of information which could constitute a human identity.

Dave

Date: Fri, 14 Apr 2000 14:35:42 -0400
To: Ed Gerck <[email-masked]>
From: Roger Younglove <[email-masked]>
Subject: Re: Missing Protocol ?
Cc: [email-masked]

I agree with both Dave and Ed, however I do not believe that a new WG is 
needed. The individual identity (carbon or silicon life form) that is 
certified with a digital certificate is the responsibility of the PKI which 
is issuing the cert. The Certificate Policy written by that PKI operator 
supplies the requirements for identification authentication. The CA CPS 
states how the CP requirements are met. It is the Relying Parties 
responsibility to properly evaluate the validity of a certificate that they 
receive. When both the CP OID and the CPS OID is included in the cert it 
becomes easy to evaluate the validity.
At 01:41 PM 4/14/2000 , you wrote:
>Dave:
>
>Yes and to your final paragraph.  A new WG would be needed -- otherwise
>this WG would need to backtrack so much that nothing would be left ;-)
>OTOH, with a new WG then what this WG has done might be a *component*
>in a bigger frame, and a useful one.
>
>Cheers,
>
>Ed Gerck
>
>"David P. Kemp" wrote:
>
> > > From: Denis Pinkas <[email-masked]>
> > > > From: Ed Gerck
> > > > Here, in PKIX, the main purpose of a CA is also to bind a public 
> key to the name
> > > > contained in the certificate and thus assure third parties that 
> some measure of care
> > > > was taken to ensure that this binding is valid for both -- i.e., 
> name and key. However,
> > > > the issue whether a user's DN actually corresponds to identity 
> credentials that are
> > > > *globally* linked to a person, or to a local alias or, simply to an 
> e-mail address -- and
> > > > how such association was verified --   is  outside the scope of 
> PKIX and depends
> > > > on each CA's CPS.
> > >
> > > I am not sure that this is really outside the scope of PKIX. If some
> > > judge would like to make the difference between John Smith 22 and
> > > John Smith 23, what can he do ? Nothing that has been standardized
> > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > should ? What kind of solution ? Being able to get back (when
> > > appropriate) the registration information (sometimes called the
> > > credentials) that has been registered at the time of registration by
> > > the RA. I do not think that it may be practical to get that
> > > information by paper and in a different format for every CA in the
> > > world. A protocol (and a schema) might be useful.
> > >
> > > Denis
> >
> > Denis,
> >
> > As long as CPSs are different, the "big identity in the sky" (the
> > information about a subject which makes John Smith 22 different from
> > John Smith 23) will be different, and outside the scope of PKIX.  If
> > the judge has access to a certain body of information:  employment and
> > credit history, property ownership and tax records, utility bills, etc,
> > and the CA has used any of that information to establish identity, then
> > the certificate may be useful to the judge.  If the CA uses only email
> > address to establish "identity", the certificate will be useless to a
> > judge dealing in non-electronic matters.  I don't see how PKIX could
> > consider in-scope an effort to develop a schema for the universe
> > of information which could constitute a human identity.
> >
> > Dave

---
TTFN
Roger W. Younglove, CISSP
Sr. Network Security Consultant
NetworkCare® Security Services
100 Galleria Officentre, Ste. 200
Southfield, MI 48034
Numeric page: 888.935.6755
E-mail page:
[email-masked]
eFax number: 413.425.5368
www.lucent.com/netcare

Date: Fri, 14 Apr 2000 14:00:46 -0400
To: Anders Rundgren <[email-masked]>, "Heimberg, Jim" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: RE: Global unique identifier
Cc: "[email-masked]" <[email-masked]>

At 04:29 PM 4/13/2000 +0200, Anders Rundgren wrote:

>There are very few global standards for this, but CAs usually have 
>restricted geographic coverage.

Usually????

SInce most CAs deployed today are within businesses.

And many businesses are global.

And some of these businesses are planning on central CAs with regional RAs....

You should see General Motor's  DN's (unless they changed them from 6 
months ago).  Of course GM DOES have at least one  CA in each country, but 
they are all rooted in c=US.

In the long run, most certificates are going to be issued by private CAs 
for business use.  DNs will reflect business needs, and there will be only 
lip service to national boundaries.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Fri, 14 Apr 2000 10:41:33 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: Missing Protocol ?
To: "David P. Kemp" <[email-masked]>, "[email-masked]" <[email-masked]>

Dave:

Yes and to your final paragraph.  A new WG would be needed -- otherwise
this WG would need to backtrack so much that nothing would be left ;-)
OTOH, with a new WG then what this WG has done might be a *component*
in a bigger frame, and a useful one.

Cheers,

Ed Gerck

"David P. Kemp" wrote:

> > From: Denis Pinkas <[email-masked]>
> > > From: Ed Gerck
> > > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > > contained in the certificate and thus assure third parties that some measure of care
> > > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > > the issue whether a user's DN actually corresponds to identity credentials that are
> > > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > > how such association was verified --   is  outside the scope of PKIX and depends
> > > on each CA's CPS.
> >
> > I am not sure that this is really outside the scope of PKIX. If some
> > judge would like to make the difference between John Smith 22 and
> > John Smith 23, what can he do ? Nothing that has been standardized
> > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > should ? What kind of solution ? Being able to get back (when
> > appropriate) the registration information (sometimes called the
> > credentials) that has been registered at the time of registration by
> > the RA. I do not think that it may be practical to get that
> > information by paper and in a different format for every CA in the
> > world. A protocol (and a schema) might be useful.
> >
> > Denis
>
> Denis,
>
> As long as CPSs are different, the "big identity in the sky" (the
> information about a subject which makes John Smith 22 different from
> John Smith 23) will be different, and outside the scope of PKIX.  If
> the judge has access to a certain body of information:  employment and
> credit history, property ownership and tax records, utility bills, etc,
> and the CA has used any of that information to establish identity, then
> the certificate may be useful to the judge.  If the CA uses only email
> address to establish "identity", the certificate will be useless to a
> judge dealing in non-electronic matters.  I don't see how PKIX could
> consider in-scope an effort to develop a schema for the universe
> of information which could constitute a human identity.
>
> Dave

Date: Fri, 14 Apr 2000 13:25:23 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Missing Protocol ?
To: [email-masked]
Content-MD5: rzgxm05PeNUjejNXza7Vcw==

> From: Denis Pinkas <[email-masked]>
> > From: Ed Gerck
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > contained in the certificate and thus assure third parties that some measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > the issue whether a user's DN actually corresponds to identity credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX and depends
> > on each CA's CPS.
> 
> I am not sure that this is really outside the scope of PKIX. If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.
> 
> Denis

Denis,

As long as CPSs are different, the "big identity in the sky" (the
information about a subject which makes John Smith 22 different from
John Smith 23) will be different, and outside the scope of PKIX.  If
the judge has access to a certain body of information:  employment and
credit history, property ownership and tax records, utility bills, etc,
and the CA has used any of that information to establish identity, then
the certificate may be useful to the judge.  If the CA uses only email
address to establish "identity", the certificate will be useless to a
judge dealing in non-electronic matters.  I don't see how PKIX could
consider in-scope an effort to develop a schema for the universe
of information which could constitute a human identity.

Dave

Date: Fri, 14 Apr 2000 10:08:00 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: Global unique identifier
To: "Heimberg, Jim" <[email-masked]>
Cc: Denis Pinkas <[email-masked]>, [email-masked]

"Heimberg, Jim" wrote:

> No, they would not choose different CAs, but the Registration Authority
> would be required to add a suffix in order to make the DN different such as
> Jim Jones1, Jim Jones2, etc.

This does not work for several reasons. First, the CA usually doubles as
a RA.  Second, who gets #1? Third, the Jim Joneses can ask,  why should
I accept and live with a protocol that forces a name change in order to
cope with what the protocol intends to *represent*? Further, of course,
it would not match their driver's license, for example -- which is at least
less demanding on how people's names are given.  Not last and not
least, someone can be rightully called "Jim Jones1" in many countries
and that someone would then conflict with the first Jim Jones in line
at that CA.  Finally,  then all CAs should name *everyone* with a
an appended "1" -- just in case someone else comes in with that
same name and we don't have to change the first one's DN ;-)

Cheers,

Ed Gerck

Date: Fri, 14 Apr 2000 09:58:54 -0700
From: Ed Gerck <[email-masked]>
Subject: Yes, Re: Missing Protocol ?
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]

Denis Pinkas wrote:

> There is one point in your E-mail I would like to comment.
>
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > contained in the certificate and thus assure third parties that some measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > the issue whether a user's DN actually corresponds to identity credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX and depends
> > on each CA's CPS.
>
> I am not sure that this is really outside the scope of PKIX.

By your comment below, I think we both agree that indeed it IS (present tense)
outside the scope of PKIX and depends on each CA's CPS -- you write "what
can he do ? Nothing that has been standardized today. :-(  In PKIX we currently
do not offer any solution".

That was my point exactly.  Now, should we (in the future) offer it ? -- as
you also ask:

> If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.

I like your approach and asking this question (going back to the
credentials) was at the root of my approach to non-repudiation
last fall. Non-repudiation (as I see it) is a necessary functionality
insofar as it can be used to negate that which might be false (e.g.
a wrong credential) -- not only doing "timestamping"and then
calling that the end-all be-all of non-repudiation (which, BTW,
is not what Tom Ginding says in his RFC for time-stamped non-
repudiation but it is how it stands today because there is no such
protocol).

So, Yes. The missing protocol thus exists IMO and is called non-repudiation
with all its bells and whistles.  In short, the ability to query the validity
of records, not just take them at their face value.

Now, whether this WG charter supports this discussion, I am not sure.
There were some voices last fall (including the WG's co-chair) against
moving any further in this direction than saying "this will be defined
by each CA's CPS".

Comments?

Cheers,

Ed Gerck

Date: Fri, 14 Apr 2000 10:44:52 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: minutes & slides
Cc: [email-masked]

Peter,

I will clarify the minutes to note that the editor of the minutes 
[me] is raising the question about whether the protocol in question 
is within scope.

Steve

Date: Fri, 14 Apr 2000 10:36:05 -0400
To: Stephen Kent <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Permanent identifiers in QC
Cc: [email-masked], [email-masked]

I agree with Steve.  Note that the CAT Working Group has defined an 
OTHER-NAME for Kerberos names.

Russ

At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
>Tom,
>
>I have no problems with the sorts of IDs you proposed in your ASN 
>GeneralName Other-Name examples. They seem to be consistent with the 
>arguments that Denis has made for such constructs. However, before we add 
>these to the updated part 1, I think we need more time to explore the 
>utility for these name forms.  The debate on the list shows that there are 
>widely diverse opinions about what such IDs are good for, what scope is 
>feasible/appropriate, etc.  I'd hesitant to hold up progress on the 
>revision to 2459 to add this sort of facility which has been proposed only 
>recently.  That's why several folks have suggested a separate, small 
>document whoch can be advanced separately, and merged into 2459 if there 
>is sufficient, consistent support.
>
>Steve

Date: Fri, 14 Apr 2000 08:12:32 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Global unique identifier

Let's remember that the original purpose of X.509 was to 
allow authentication of a user to the directory ITSELF. Since
the DN in the directory was the controlling index used to look up 
all the other stuff, it by definition had to be unique in that directory.
Otherwise the directory would have been a relational database.

Then the PKI community came along and said, "Oh, that's nice" and
appropriated the syntax of X.509 without ever bothering to define the
semantics of what a DN really meant in their new context.

There was sort of a vague hope that a DN would actually be meaningful, 
despite the experience of many deployed directories to the contrary --
directory administrators set up directories for their own convenience, and 
sometimes for the convenience of the larger organization, but hardly
ever for the convenience of external users who might be inclined
to actually RELY on the DN.

So the DN in a directory is primarily Distinguished, i.e., unique within that
directory; and only secondarily, if at all, useful as an actual Name. Case
in point, my own DN or NetWare "context": 
bjueneman.nsrd.prv.novell.

Now there 's a name a mother could really grow to love! But it is unique, at least
within Novell's directory.

Well, 'sez some, how about using a subjectAltName? Good idea, bad execution,
at least so far: subjectAltName=[email-masked]. From the standpoint 
of providing human recognizable information, that's even worse -- it doesn't even
provide a hint to anyone where I work, or in what organization. I guess it's
better than [email-masked], but not by much.

You say that you'd like to have a name that more or less corresponds to
the name I am known by in social circles (no, not that name, the polite one)?
Or you'd like to have something that corresponds to my business card, or maybe 
a residential address, in case you want to send the sheriff after me?

Then put yet another subjectAltName in the certificate, this time a REAL one,
e.g., c=US, o="Novell, Inc." ou="Network Security Department", 
title="Security Architect", cN="Robert R. Jueneman"

Or even more informatively:, if backwards by conventional envelope 
addressing conventions:
c=US, o="Novell, Inc." ou="Network Security Department", s=Utah, l=Provo,
steetAddress="1800 South Novell Place", 
title="Security Architect", cN="Robert R. Jueneman"

Of course, it might have been nice to label these subjectAltNames
more informatively, as a hint to applications that have to display them, e.g.,
rfc822Name=..., organizationalPersonName=..., residentialPersonName=...
but I guess it's too late for that now. "Syntax first, semantics later, if
at all" is our motto, right, boys?

Oh well, maybe we'll get it right eventually. Son of son of 2459, maybe?
Sounds like a Russian patronymic, or maybe an SPKI reference. :-)

Bob

>>> Ed Gerck <[email-masked]> 04/14/00 12:08AM >>>

"Ramsay, Ron" wrote:

> Ed,
>
> I think we all know about the shortcomings of DNs and, as far as X.509 is
> concerned, I don't think we're going to see The Global Directory(TM).

not with that technology, but X.500 is not the end-all be-all of database
development -- new paradigms may always appear.

> My point, and I don't think you answered it, is that a CA can get it names
> from anywhere, the moon perhaps, and there may be clashes in the 'global'
> name space. But, as long as they are unique in all the DNs which have been
> associated with the CA's DN by a certificate, they will be a unique
> identifier for that CA.

We may agree that you are postulating the answer to your question -- so, no
wonder you get it. What you are saying is equivalent to "if names are unique
in a CA, then they are unique in that CA".

Now, let's try a real-world case, where two "Jim Jones" want to get a certificate
from Verisign -- why would the second one need to accept a different DN? More
probably, rather than being forced to accept a different DN he would look for a
different CA, which is of course not acceptable commercially for the first cert vendor.

The bottom line? Semantically, the CA certificate refers to a name; however it does
not denote it. Therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
local matter (local to the CA and its CPS) even if X.500 global directories were used
(X.509v3, Section 11.2). Of course, if the US INS accepts (rather, "uses") UK birth
certificates in order to issue residence permits to the US, this does not mean that the
INS is declaring that such birth certificates are valid in the UK. So, the eventual use
by a CA of a DN supplied by a X.500 directory does not mean that the CA is
declaring that such DN is global -- or, globally unique.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified -- is outside the scope of PKIX and depends
on each CA's CPS.

Cheers,

Ed Gerck

Date: Fri, 14 Apr 2000 14:03:31 +0200
To: Volker Hammer <[email-masked]>, "PKIX Mailing List" <[email-masked]>
From: Juergen Brauckmann <[email-masked]>
Subject: Re: Encoding of  "dc" in DNs

At 18:05 13.04.00 +0200, Volker Hammer wrote:
>Hi,
>
>we use the "dc"-Attribute (domain component) to build distinguished names
in multinational enterprises.
>
>We need to decide how the "dc"-attribute should be encoded in
implementations of the subject distinguished name and issuer dn within
certificates as well as for X.500 directory information tree distinguished
names. RFC2247 (X.500 OID DomainComponent) tells "IA5 string". Some CA
products use "printableString", which is in accordance with recommendation
of "DirectoryString" in X.500 ff. But the latter is only a recommendation
and not enforced, so IA5 string seems to be correct.

DC is defined as type "IA5String" in RFC2247. 

"DirectoryString" is an own type which is used in components of DNs. But
not all DN-Components need to be of type DirectoryString. domainComponent
is *not* of type DirectoryString, but of type IA5String, so it is
definitely an error to encode a DC as a PrintableString.

>* Will interop problems in clients arise when using "the other" encoding
(client expects IA5 but find 
>printableString and vice versa)

That depends, of course... . 

Regards,
   Juergen Brauckmann
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de	

Content-return: allowed
Date: Fri, 14 Apr 2000 07:41:34 -0400
From: "Heimberg, Jim" <[email-masked]>
Subject: RE: Global unique identifier
To: "'Ed Gerck'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]

No, they would not choose different CAs, but the Registration Authority
would be required to add a suffix in order to make the DN different such as
Jim Jones1, Jim Jones2, etc.

Subject: Re: Global unique identifier

Denis Pinkas wrote:

> > Denis,
> >         I am not sure I understand why the DN would not be globally
unique.
>
> This was the ISO dream in the 90's.  :- )
>
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.

Yes, and according to X.509, it may not even be unique within
*the same* CA.  Or, would the Jim Jones have all to choose different CAs?

More on this  in http://www.mcg.org.br/certover.pdf

Cheers,

Ed Gerck

Date: Fri, 14 Apr 2000 12:48:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Ed Gerck <[email-masked]>
CC: [email-masked]
Subject: Missing Protocol ?

Ed,

Your message was sent to the "Global unique identifier" thread.
Since I am adressing a different topic, I changed the  name of that
thread.

<snip>

There is one point in your E-mail I would like to comment.

> Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> contained in the certificate and thus assure third parties that some measure of care
> was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> the issue whether a user's DN actually corresponds to identity credentials that are
> *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> how such association was verified --   is  outside the scope of PKIX and depends
> on each CA's CPS.

I am not sure that this is really outside the scope of PKIX. If some
judge would like to make the difference between John Smith 22 and
John Smith 23, what can he do ? Nothing that has been standardized
today. :-(  In PKIX we currently do not offer any solution. Maybe we
should ? What kind of solution ? Being able to get back (when
appropriate) the registration information (sometimes called the
credentials) that has been registered at the time of registration by
the RA. I do not think that it may be practical to get that
information by paper and in a different format for every CA in the
world. A protocol (and a schema) might be useful.

Denis

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 Apr 2000 12:02:50 +0200 (MET DST)
To: [email-masked]
Subject: Re: minutes & slides
Cc: [email-masked]

> 
> >  >
> >  > DVCS  (P. Sylvester-EdelWeb)
> >  > This is the current version of the document that began as a notary
> >  > protocol from Adams & Zuccherato, and then became the data
> >  > certification service protocols, before editorial responsibility
> >  > shifted. Motivation for this protocol is to support a central
> >  > infrastructure for document security management, e.g., in an intranet
> >  > or extranet environment, or for other long term secure document
> >  > management. The protocol is designed to enable delegation of
> >  > signature verification, notarization, and even certificate use
> >  > controls to a server (vs. and end system). The presentation included
> >  > a number of scenarios motivating the need for the protocol and its
> >  > features. The question arises whether the complex document management
> >  > system features described here is really an infrastructure component
> >  > within the purview of this WG or it is more of an application? (See
> >  > slides for more details.)
> >
> >This question does NOT arise:
> >
> >  >From goals and milestones of the working group:
> >
> >Dec 99 : Complete data certification document
> >
> >The question was: Are 31 pages too complicated to read for people
> >(just 10 pages more than in time stamping).
> >
> >I would not be surprised if someone thinks that
> >31 are definetely not enough to describe a 'complex' protocol.
> 
> If the protocol has become very complex because it attempts to embody 
> features needed to support a rather complete document management 
> scenario, then it may have crossed the boundary from infrastructure 
> protocol to application protocol.  The WG will have to decide on this 
> issue, after reviewing the document.

The question is worth to be discussed in PKIX, and I believe that dvcs
is also woth to be discussed in the smime group, be it for the simple
reason that it uses cms documents,

but here we are talking about minutes of a meeting.

I have made a presentation, and asked some questions (see slides), 
and there was a question from the audience, if I remember it
correctly, please feel free to correct me if I am wrong. 

From: "Lunow, Pauwl PB SSI-GPCS" <[email-masked]>
To: [email-masked]
Subject: unsubscribe
Date: Fri, 14 Apr 2000 08:55:32 +0200

unsubscribe

Date: Thu, 13 Apr 2000 23:08:26 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: Global unique identifier
To: "Ramsay, Ron" <[email-masked]>
Cc: [email-masked]

"Ramsay, Ron" wrote:

> Ed,
>
> I think we all know about the shortcomings of DNs and, as far as X.509 is
> concerned, I don't think we're going to see The Global Directory(TM).

not with that technology, but X.500 is not the end-all be-all of database
development -- new paradigms may always appear.

> My point, and I don't think you answered it, is that a CA can get it names
> from anywhere, the moon perhaps, and there may be clashes in the 'global'
> name space. But, as long as they are unique in all the DNs which have been
> associated with the CA's DN by a certificate, they will be a unique
> identifier for that CA.

We may agree that you are postulating the answer to your question -- so, no
wonder you get it.  What you are saying is equivalent to "if names are unique
in a CA, then they are unique in that CA".

Now, let's try a real-world case, where two "Jim Jones" want to get a certificate
from Verisign -- why would the second one need to accept a different DN?  More
probably, rather than being forced to accept a different DN he would look for a
different CA, which is of course not acceptable commercially for the first cert vendor.

The bottom line?  Semantically, the CA certificate refers to a name; however it does
not denote it.  Therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
local matter (local to the CA and its CPS) even if X.500 global directories were used
(X.509v3, Section 11.2). Of course, if the US INS accepts (rather, "uses") UK birth
certificates in order to issue residence permits to the US, this does not mean that the
INS is declaring that such birth certificates are valid in the UK. So, the eventual use
by a CA of a DN supplied by a X.500 directory does not mean that the CA is
declaring that such DN is global -- or, globally unique.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified --   is  outside the scope of PKIX and depends
on each CA's CPS.

Cheers,

Ed Gerck

From: "Ramsay, Ron" <[email-masked]>
To: Ed Gerck <[email-masked]>
Cc: [email-masked]
Subject: RE: Global unique identifier
Date: Fri, 14 Apr 2000 14:21:13 +1000

Ed,

I think we all know about the shortcomings of DNs and, as far as X.509 is
concerned, I don't think we're going to see The Global Directory(TM).

My point, and I don't think you answered it, is that a CA can get it names
from anywhere, the moon perhaps, and there may be clashes in the 'global'
name space. But, as long as they are unique in all the DNs which have been
associated with the CA's DN by a certificate, they will be a unique
identifier for that CA.

Jim Heimberg's message was:

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

I'm simply saying that the 'domain' is not something like: All DNs; or: All
DNs under o=Ace Industry,c=US. I'm saying that the domain is: All DNs in
certificates issued by the CA.

Ron.

-----Original Message-----
From: Ed Gerck [mailto:[email-masked]]
Sent: Friday, 14 April 2000 12:56
To: Ramsay, Ron
Cc: [email-masked]; Anders Rundgren; 'Denis Pinkas'; 'Heimberg, Jim'
Subject: Re: Global unique identifier

"Ramsay, Ron" wrote:

> But surely the domain of the CA is the totality of subject DNs in all
> certificates issued by the CA. For two DNs to be the same in the CAs
domain
> they must each be the subject DN of a certificate naming the CA as issuer.

 Section 11.2 of X.509v3, "Management of certificates", states that the
certificate
 allows an association between a name called "unique distinguished name" or
DN
 for the user and  the user's public-key: "A  certificate  associates  the
public key
 and unique distinguished name of the user it describes.", while Section 7
explains
 that such DNs are essential to the security design of X.509:
"Authentication relies
 on each user possessing a unique distinguished name." But, how are such DNs
 assigned? Where are they unique? The DN is  denoted by a NA (Naming
Authority)
 and accepted by a CA (Certification Authority) as unique within the CA's
domain,
 where the CA can double as a NA. It is interesting to  note that the same
user can
 have different DNs in different CAs, or can use the same DN in different
CAs even
 if it is not the first one to use it in a CA -- so different DNs for
different CAs do not
 necessarily mean different users and vice-versa. Further, a DN does not
have to
 contain the user's real-world name or location. Thus, semantically, the CA
 certificate refers to a name; however it does not denote it.

(in http://www.mcg.org.br/cert.htm)

Cheers,

Ed Gerck

Date: Thu, 13 Apr 2000 19:56:23 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: Global unique identifier
To: "Ramsay, Ron" <[email-masked]>
Cc: [email-masked], Anders Rundgren <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Heimberg, Jim'" <[email-masked]>

"Ramsay, Ron" wrote:

> But surely the domain of the CA is the totality of subject DNs in all
> certificates issued by the CA. For two DNs to be the same in the CAs domain
> they must each be the subject DN of a certificate naming the CA as issuer.

 Section 11.2 of X.509v3, "Management of certificates", states that the certificate
 allows an association between a name called "unique distinguished name" or DN
 for the user and  the user's public-key: "A  certificate  associates  the public key
 and unique distinguished name of the user it describes.", while Section 7 explains
 that such DNs are essential to the security design of X.509: "Authentication relies
 on each user possessing a unique distinguished name." But, how are such DNs
 assigned? Where are they unique? The DN is  denoted by a NA (Naming Authority)
 and accepted by a CA (Certification Authority) as unique within the CA's domain,
 where the CA can double as a NA. It is interesting to  note that the same user can
 have different DNs in different CAs, or can use the same DN in different CAs even
 if it is not the first one to use it in a CA -- so different DNs for different CAs do not
 necessarily mean different users and vice-versa. Further, a DN does not have to
 contain the user's real-world name or location. Thus, semantically, the CA
 certificate refers to a name; however it does not denote it.

(in http://www.mcg.org.br/cert.htm)

Cheers,

Ed Gerck

Date: Fri, 14 Apr 2000 01:11:25 +0800
From: Gao Yuhang <[email-masked]>
To: pki_ietf list <[email-masked]>
Subject: pki product report

	Please excuse for off-topic. But can anyonehelp me to find
reports on current PKI products,with explanations and comparisions, such
as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate Server?

Thanks,
Hazel
 ______________________________________________
  Miss Yuhang Gao
  Network Center, Computer Dept.
  Southeast University,
  Nanjing, Jiangsu,
  P.R.China
  210096

Date: Fri, 14 Apr 2000 11:21:11 +0900
To: [email-masked]
From: Takuya INOUE <[email-masked]>

subscribe
  ___\____ ----------------------------------------
 |        |      NTT Communications Corporation 
 | <>  <> | (( ))      Advanced Business Works
 |   __   | //             Takuya INOUE
 |________|//    [email-masked]
TEL:+81 3 5353 3377    Fax:+81 3 5353 5670
           ----------------------------------------

From: "Ramsay, Ron" <[email-masked]>
To: [email-masked]
Cc: Anders Rundgren <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Heimberg, Jim'" <[email-masked]>
Subject: RE: Global unique identifier
Date: Fri, 14 Apr 2000 11:10:21 +1000

But surely the domain of the CA is the totality of subject DNs in all
certificates issued by the CA. For two DNs to be the same in the CAs domain
they must each be the subject DN of a certificate naming the CA as issuer.

There is still a uniqueness problem which is to distinguish between two John
Smiths. For this the CA would require a DN disambiguator.

Ron.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Thursday, 13 April 2000 22:21
To: 'Denis Pinkas'; 'Heimberg, Jim'
Cc: [email-masked]
Subject: RE: Global unique identifier

Jim,
You are absolutely right that DNs should be globally unique within their
domain. 
The only problem is that we do not have any means (or do we?) to specify (in
a certificate) a domain 
which may be internal (NULL) to the CA or external (hopefully centrally
registered like IPs, OIDs etc.).   
Anders
----------
From:  Heimberg, Jim [SMTP:[email-masked]]
Sent:  Thursday, April 13, 2000 14:13
To:  'Denis Pinkas'; Anders Rundgren
Cc:  [email-masked]
Subject:  RE: Global unique identifier

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Global unique identifier

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders

From: [email-masked]
Subject: Warning: PKIX Freeware Library may be withdrawn
To: [email-masked], [email-masked]
Date: Thu, 13 Apr 2000 17:57:48 -0400

I thought I should alert people to a situation evolving concerning the PKIX
Freeware Library that was jointly written by Iris, Lotus, and IBM. The
source code for all but the crypto has been available on
http://web.mit.edu/pfl for domestic distribution and on
http://www.foobar.com/jonah for worldwide distribution for some time. It
excludes crypto functions that are available separately from Cylink.

Included in the PKIX Freeware Library code is some crypto interface code
originally developed by Intel and adapted to this use. Intel recently
announced publicly that they are releasing for free distribution a large
body of crypto interface code that includes a newer version of that
interface. But there are indications that they are also going to declare
the version used by PKIX to no longer be freely distributable.

If that happens, we will be required to pull the code from all posting
sites under our control. I thought I should let people know in case this
affects their plans to embed this code in other products.

The PKIX Freeware Library could be adapted to use the new versions of the
Intel crypto interfaces, or more likely could replace them with direct
interfaces to the Cylink code. But I am not aware of anyone planning to do
that work. If anyone does so, I hope they will post it so that others can
take advantage of it.

     --Charlie Kaufman
     ([email-masked])

Disclaimer: Opinions expressed may not even by mine by the time you read
them, and certainly do not represent those of any other legal entity. It's
also possible that this message is not from me at all, but rather was
forged.

Date: Thu, 13 Apr 2000 12:48:32 -0700
From: Ed Gerck <[email-masked]>
Subject: Re: Global unique identifier
To: Denis Pinkas <[email-masked]>
Cc: "Heimberg, Jim" <[email-masked]>, [email-masked]

Denis Pinkas wrote:

> > Denis,
> >         I am not sure I understand why the DN would not be globally unique.
>
> This was the ISO dream in the 90's.  :- )
>
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.

Yes, and according to X.509, it may not even be unique within
*the same* CA.  Or, would the Jim Jones have all to choose different CAs?

More on this  in http://www.mcg.org.br/certover.pdf

Cheers,

Ed Gerck

Date: Thu, 13 Apr 2000 18:05:05 +0200
To: "PKIX Mailing List" <[email-masked]>
From: Volker Hammer <[email-masked]>
Subject: Encoding of  "dc" in DNs

Hi,

we use the "dc"-Attribute (domain component) to build distinguished names in multinational enterprises.

We need to decide how the "dc"-attribute should be encoded in implementations of the subject distinguished name and issuer dn within certificates as well as for X.500 directory information tree distinguished names. RFC2247 (X.500 OID DomainComponent) tells "IA5 string". Some CA products use "printableString", which is in accordance with recommendation of "DirectoryString" in X.500 ff. But the latter is only a recommendation and not enforced, so IA5 string seems to be correct.

Questions:

* Will interop problems in clients arise when using "the other" encoding (client expects IA5 but find printableString and vice versa)

* Products using printableString: will this be corrected in accordance to RFC2247?

* Other recommendations from the list?

Thanks in advance,
Volker Hammer.
--------------------------------------------------------
Dr.-Ing. Volker Hammer
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-458, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
--------------------------------------------------------
PGP-Fingerprint    3C9C AD64 AC6B 64CC  FA6B AE8D 2A5D 462D

Date: Thu, 13 Apr 2000 14:02:59 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Permanent identifiers in QC
Cc: [email-masked]

Tom,

I have no problems with the sorts of IDs you proposed in your ASN 
GeneralName Other-Name examples. They seem to be consistent with the 
arguments that Denis has made for such constructs. However, before we 
add these to the updated part 1, I think we need more time to explore 
the utility for these name forms.  The debate on the list shows that 
there are widely diverse opinions about what such IDs are good for, 
what scope is feasible/appropriate, etc.  I'd hesitant to hold up 
progress on the revision to 2459 to add this sort of facility which 
has been proposed only recently.  That's why several folks have 
suggested a separate, small document whoch can be advanced 
separately, and merged into 2459 if there is sufficient, consistent 
support.

Steve

From: Ken Allen <[email-masked]>
To: [email-masked]
Subject: testing
Date: Thu, 13 Apr 2000 10:54:36 -0600

From: Paul Halliden <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 18:08:11 +0100

<snip>

>Actually I don't understand how tax authorities can separate 
>the two Delta Companies
>if there are no naming conventions.

Quite simple - In this country (UK) the tax man allocates his own account
number to each.  If both Deltas are actually the same company, it soon
complains when it gets two tax bills.  The tax man can use a mass of
information that exists in the real world to establish whether there really
is one or two and adjust its account numbering scheme accordingly.  The
point is that in real life there are plenty of name collisions which can be
resolved in a given domain provided that domain has control over its naming
convention.

Paul Halliden

Date: Thu, 13 Apr 2000 11:03:55 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Global unique identifier

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_4B128B10.4120CB0C
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

That's why most countries use a taxpayer ID.  Even though they aren't =
guaranteed to always be unique across time and space, they reduce the =
possibility that the combination of name and number is not unique to a =
level that is negligible.  Not zero, perhaps, but negligible.

DON'T assume, however, that CAs have restricted geographic coverage, for =
that certainly isn't so.  Europe isn't like the US, and vice versa. We =
fell into that trap within the NADF about 8 years ago, when we assumed =
that monopoly telephone carriers (remember those?)  had territories that =
corresponded to geopolitical boundaries.  Turns out that wasn't true even =
then, and  most certainly isn't now.

I'm sure that VeriSign would be willing to sell you a certificate =
regardless of where you live/reside/are domiciled/are a citizen of/vote/own=
 a second residence/are currently travelling/etc.  For that matter, so =
would we.

Bob

>>> Anders Rundgren <[email-masked]> 04/13/00 08:29AM >>>
Denis,

<snip>

>A CA can nominate the Delta Company from country FR, but another CA
>can nominate another Delta Company from the same country. There
>cannot be an ambiguity on the country name, because the way country
>names are used is well described. For any other level, the
>interpretation is free. Thus there is no way to make sure that the
>two Delta companies are the same, since there is no naming authority
>telling how "Delta Company" should be interpreted or undertsood.

This is perfectly valid in regions where no registration system exists.  =
In country SE
this has been solved in the same way as for persons.  Permanent unique =
IDs.

Actually I don't understand how tax authorities can separate the two Delta =
Companies
if there are no naming conventions.

There are very few global standards for this, but CAs usually have =
restricted geographic coverage.

<snip>

Anders

--=_4B128B10.4120CB0C
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>That's why most countries use a taxpayer ID.&nbsp; =
Even though=20
they aren't guaranteed to always be unique across time and space, they =
reduce=20
the possibility that the combination of name and number is not unique to a =
level=20
that is negligible.&nbsp; Not zero, perhaps, but negligible.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>DON'T assume, however, that CAs have restricted =
geographic=20
coverage, for that certainly isn't so.&nbsp; Europe isn't like the US, and =
vice=20
versa. We fell into that trap within the NADF about 8 years ago, when we =
assumed=20
that monopoly telephone carriers (remember those?)&nbsp; had territories =
that=20
corresponded to geopolitical boundaries.&nbsp; Turns out that wasn't true =
even=20
then, and&nbsp; most certainly isn't now.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I'm sure that VeriSign would be willing to sell you =
a=20
certificate regardless of where you live/reside/are domiciled/are a =
citizen=20
of/vote/own a second residence/are currently travelling/etc.&nbsp; For =
that=20
matter, so would we.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT><BR><BR>&gt;&gt;&gt; Anders Rundgren=20
&lt;[email-masked]&gt; 04/13/00 08:29AM=20
&gt;&gt;&gt;<BR>Denis,<BR><BR>&lt;snip&gt;<BR><BR>&gt;A CA can nominate =
the=20
Delta Company from country FR, but another CA<BR>&gt;can nominate another =
Delta=20
Company from the same country. There<BR>&gt;cannot be an ambiguity on =
the=20
country name, because the way country<BR>&gt;names are used is well =
described.=20
For any other level, the<BR>&gt;interpretation is free. Thus there is no =
way to=20
make sure that the<BR>&gt;two Delta companies are the same, since there is =
no=20
naming authority<BR>&gt;telling how "Delta Company" should be interpreted =
or=20
undertsood.<BR><BR>This is perfectly valid in regions where no registration=
=20
system exists.&nbsp; In country SE<BR>this has been solved in the same way =
as=20
for persons.&nbsp; Permanent unique IDs.<BR><BR>Actually I don't understand=
 how=20
tax authorities can separate the two Delta Companies<BR>if there are no =
naming=20
conventions.<BR><BR>There are very few global standards for this, but =
CAs=20
usually have restricted geographic=20
coverage.<BR><BR>&lt;snip&gt;<BR><BR>Anders<BR><BR><BR></DIV></BODY></HTML>=

--=_4B128B10.4120CB0C--

Date: Thu, 13 Apr 2000 18:23:42 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Janus Liebregts <[email-masked]>
CC: "Heimberg, Jim" <[email-masked]>, [email-masked], "Valkenburg, Peter" <[email-masked]>
Subject: Re: Global unique identifier

> Denis Pinkas wrote:
> >
> > > Denis,
> > >         I am not sure I understand why the DN would not be globally unique.
> >
> > This was the ISO dream in the 90's.  :- )
> 
> This is still our dream in the Netherlands. In our policy we only
> certify DN's which are stored in our ldap-DIT:
> http://ldap.surfnet.nl:8888/ The DN's certificates are stored in their
> ldap-entries.

You give water to Anders's mill. :-)

In your case you would say that the naming authority is something
like: "Netherlands ldap-DIT".

Introducing that component as a part of the DN may allow you to have
that uniqueness. However ... the syntax of the name would be
correct, but the semantics would not change, ... unless in the CP
policy (which is not easily universally machine processable) you
state that the presence of that component implies that the name that
follows it is unique for the Netherlands.

Anders was looking, I guess, for generic way to express that
uniqueness (i.e. not using the CP). There would be various solutions
for that, including an extension to the DN syntax.

Regards,

Denis 

> For the c=nl we can guarantee names are unique, in a european effort we
> try to couple national ldap-infrastructures see:
> http://www.terena.nl/task-forces/ http://www.dante.net
> 
> on a local base we think about delegating the c=nl, o=... to the dutch
> Chamber of Commerce and the c=nl, l=... to the ministry responsible for
> the dutch localities.
> 
> I think naming is a policy matter.
> 
> Janus Liebregts
> SURFnet
> The Netherlands
> 
> >
> > A CA can nominate the Delta Company from country FR, but another CA
> > can nominate another Delta Company from the same country. There
> > cannot be an ambiguity on the country name, because the way country
> > names are used is well described. For any other level, the
> > interpretation is free. Thus there is no way to make sure that the
> > two Delta companies are the same, since there is no naming authority
> > telling how "Delta Company" should be interpreted or undertsood.
> >
> > > If it is unique within its domain, there should not be duplication of
> > > domains and thus it becomes globally unique.
> >
> > No. As explained above, unique within the CA domain does not mean
> > universally unique across all CAs.
> >
> > > Please let me know if there is some reason that this is not true.
> >
> > Done.
> >
> > Regards,
> >
> > Denis

Date: Thu, 13 Apr 2000 16:44:08 +0200
From: Janus Liebregts <[email-masked]>
Organization: SURFnet bv
To: Denis Pinkas <[email-masked]>
CC: "Heimberg, Jim" <[email-masked]>, [email-masked], "Valkenburg, Peter" <[email-masked]>
Subject: Re: Global unique identifier

Denis Pinkas wrote:
> 
> > Denis,
> >         I am not sure I understand why the DN would not be globally unique.
> 
> This was the ISO dream in the 90's.  :- )

This is still our dream in the Netherlands. In our policy we only
certify DN's which are stored in our ldap-DIT:
http://ldap.surfnet.nl:8888/ The DN's certificates are stored in their
ldap-entries.
For the c=nl we can guarantee names are unique, in a european effort we
try to couple national ldap-infrastructures see:
http://www.terena.nl/task-forces/ http://www.dante.net

on a local base we think about delegating the c=nl, o=... to the dutch
Chamber of Commerce and the c=nl, l=... to the ministry responsible for
the dutch localities.

I think naming is a policy matter. 

Janus Liebregts
SURFnet
The Netherlands

> 
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.
> 
> > If it is unique within its domain, there should not be duplication of
> > domains and thus it becomes globally unique.
> 
> No. As explained above, unique within the CA domain does not mean
> universally unique across all CAs.
> 
> > Please let me know if there is some reason that this is not true.
> 
> Done.
> 
> Regards,
> 
> Denis
> 
> > Jim
> >
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Wednesday, April 12, 2000 9:04 AM
> > To: Anders Rundgren
> > Cc: [email-masked]
> > Subject: Global unique identifier
> >
> > Anders,
> >
> > In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
> > each subject entity certified by the one CA as defined by the issuer
> > name field". There is no requirement to make the DN unique across
> > multiple CAs.
> >
> > Adding this requirement would either break RFC 2459 or build
> > something very different. Today, when a DN is used, it is a DN from
> > a given CA. Each CA may build its own tree of names. A sequence of
> > relative names forming a distinguished name from CA 1 and the same
> > sequence of names forming the same distinguished name from a CA 2 do
> > not necessarilly need to point to the same entity. So the name of
> > the CA has to be used in addition to every DN in order to make the
> > difference. In other words, if two DNs from two different CAs are
> > identical, this does not mean that the two entities are necessarilly
> > identical. This was supposed to be true, ten years ago, when the
> > Directory (with a capital D) was defined, but this is no more the
> > case today.
> >
> > Now let us make the assumption that we introduce an explicit naming
> > domain information (or naming authority information) in some form of
> > name. Note that this topic does not apply only to the permanent
> > identifier but could apply as well to the DN: this is why it should
> > be discussed on a different thread.
> >
> > As a conclusion, this particular aspect should be discussed on a
> > separate thread (I have called it "Global unique identifier" but you
> > may use any other name you prefer, as long as it is not "permanent
> > identifier").
> >
> > Denis
> >
> >
> > > Denis,
> > > <snip>
> > > >Please, do not make the story more complicated than requested. The
> > > >permanent identifier is a name of the subject, unique within the
> > > >issuer domain, that is not reused over time for another subject. The
> > > >name is only unique within the issuer domain (i.e. CA). Making the
> > > >name unique across different CAs would break the current PKIX model.
> > >
> > > The requirement stated by Tom is very valid (I have raised it on this list
> > a countless number of times)
> > > and applies 100% to what is supposed to be happening any old day here in
> > Sweden.
> > > I.e. a number of competing CAs issue certificates to a Naming Domain they
> > do not govern themselves.
> > > These identity certificates are supposed to be totally interchangeable as
> > their physical counterparts
> > > have been the last 30 years or so.  By the use of a permanent ID and
> > (implicit) naming domain.
> > >
> > > I.e. any improvement or addition to QC must address the naming domain
> > question as well.
> > > Or as Tom prefers.  The naming authority.
> > >
> > > Anders

From: Anders Rundgren <[email-masked]>
To: "Heimberg, Jim" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 16:29:45 +0200

Denis,

<snip>

>A CA can nominate the Delta Company from country FR, but another CA
>can nominate another Delta Company from the same country. There
>cannot be an ambiguity on the country name, because the way country
>names are used is well described. For any other level, the
>interpretation is free. Thus there is no way to make sure that the
>two Delta companies are the same, since there is no naming authority
>telling how "Delta Company" should be interpreted or undertsood.

This is perfectly valid in regions where no registration system exists.  In country SE
this has been solved in the same way as for persons.  Permanent unique IDs.

Actually I don't understand how tax authorities can separate the two Delta Companies
if there are no naming conventions.

There are very few global standards for this, but CAs usually have restricted geographic coverage.

<snip>

Anders

Date: Thu, 13 Apr 2000 17:29:49 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: [email-masked]
Subject: draft-ietf-pkix-new-part1-01.txt

Hello ietf-pkix!

  id-ce-holdInstructionCode and id-ce-instructionCode are aliases also.

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

Date: Thu, 13 Apr 2000 17:28:42 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: [email-masked]
Subject: draft-ietf-pkix-new-part1-01.txt

Hello ietf-pkix!

  I've also found three aliases for a same OID in
  draft-ietf-pkix-new-part1-01.txt:

id-ce-cRLReason
id-ce-cRLReasons
id-ce-reasonCode

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

Date: Thu, 13 Apr 2000 17:25:51 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: [email-masked], [email-masked]
Subject: id-ct-compressedData vs id-ct-publishCert

Hello!

  id-ct-compressedData from draft-ietf-smime-compression-00.txt and
  id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID

  In draft-ietf-smime-compression-00.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 3

  In draft-ietf-smime-certdist-04.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 3

  which is same. I've found it confusing; I would like go get a solution
  from the authors of drafts above mentioned.

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

Date: Thu, 13 Apr 2000 16:00:39 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Heimberg, Jim" <[email-masked]>
CC: [email-masked]
Subject: Re: Global unique identifier

> Denis,
>         I am not sure I understand why the DN would not be globally unique.

This was the ISO dream in the 90's.  :- ) 

A CA can nominate the Delta Company from country FR, but another CA
can nominate another Delta Company from the same country. There
cannot be an ambiguity on the country name, because the way country
names are used is well described. For any other level, the
interpretation is free. Thus there is no way to make sure that the
two Delta companies are the same, since there is no naming authority
telling how "Delta Company" should be interpreted or undertsood.

> If it is unique within its domain, there should not be duplication of
> domains and thus it becomes globally unique.  

No. As explained above, unique within the CA domain does not mean
universally unique across all CAs.

> Please let me know if there is some reason that this is not true.

Done. 

Regards,

Denis

> Jim
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 12, 2000 9:04 AM
> To: Anders Rundgren
> Cc: [email-masked]
> Subject: Global unique identifier
> 
> Anders,
> 
> In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
> each subject entity certified by the one CA as defined by the issuer
> name field". There is no requirement to make the DN unique across
> multiple CAs.
> 
> Adding this requirement would either break RFC 2459 or build
> something very different. Today, when a DN is used, it is a DN from
> a given CA. Each CA may build its own tree of names. A sequence of
> relative names forming a distinguished name from CA 1 and the same
> sequence of names forming the same distinguished name from a CA 2 do
> not necessarilly need to point to the same entity. So the name of
> the CA has to be used in addition to every DN in order to make the
> difference. In other words, if two DNs from two different CAs are
> identical, this does not mean that the two entities are necessarilly
> identical. This was supposed to be true, ten years ago, when the
> Directory (with a capital D) was defined, but this is no more the
> case today.
> 
> Now let us make the assumption that we introduce an explicit naming
> domain information (or naming authority information) in some form of
> name. Note that this topic does not apply only to the permanent
> identifier but could apply as well to the DN: this is why it should
> be discussed on a different thread.
> 
> As a conclusion, this particular aspect should be discussed on a
> separate thread (I have called it "Global unique identifier" but you
> may use any other name you prefer, as long as it is not "permanent
> identifier").
> 
> Denis
> 
> 
> > Denis,
> > <snip>
> > >Please, do not make the story more complicated than requested. The
> > >permanent identifier is a name of the subject, unique within the
> > >issuer domain, that is not reused over time for another subject. The
> > >name is only unique within the issuer domain (i.e. CA). Making the
> > >name unique across different CAs would break the current PKIX model.
> >
> > The requirement stated by Tom is very valid (I have raised it on this list
> a countless number of times)
> > and applies 100% to what is supposed to be happening any old day here in
> Sweden.
> > I.e. a number of competing CAs issue certificates to a Naming Domain they
> do not govern themselves.
> > These identity certificates are supposed to be totally interchangeable as
> their physical counterparts
> > have been the last 30 years or so.  By the use of a permanent ID and
> (implicit) naming domain.
> >
> > I.e. any improvement or addition to QC must address the naming domain
> question as well.
> > Or as Tom prefers.  The naming authority.
> >
> > Anders

Date: Thu, 13 Apr 2000 16:47:40 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: [email-masked], [email-masked]
Subject: duplicate aliases of the same OID in draft-ietf-pkix-new-part1-01.txt

Hello!

  I've found duplicate aliases of the same OID in
  draft-ietf-pkix-new-part1-01.txt

  sha-1WithRSAEncryption (section 7.2.1) and sha1WithRSAEncryption
  (elsewhere).

  The first variant was also found in rfc2632, rfc2633 (along with the
  second variant).

  Second variant was also found in draft-ietf-smime-certdist-04.txt,
  draft-ietf-smime-examples-03.txt and rfc2633.

  There are also numerous duplicate OID aliases, for example
  PKCS#9-relaeted; they are different in PKIX documents, S/MIME
  documents and PKCS#9 itself.
  
  I've found it writing my ASN.1 code to work with S/MIME messages and
  X.509 certificates. Having multiple names of a same OIDS is much worse
  than having one, I think both workgroups should take care of that.
  
-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Heimberg, Jim'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 14:21:21 +0200

Jim,
You are absolutely right that DNs should be globally unique within their domain. 
The only problem is that we do not have any means (or do we?) to specify (in a certificate) a domain 
which may be internal (NULL) to the CA or external (hopefully centrally registered like IPs, OIDs etc.).   
Anders
----------
From:  Heimberg, Jim [SMTP:[email-masked]]
Sent:  Thursday, April 13, 2000 14:13
To:  'Denis Pinkas'; Anders Rundgren
Cc:  [email-masked]
Subject:  RE: Global unique identifier

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Global unique identifier

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders

Content-return: allowed
Date: Thu, 13 Apr 2000 08:12:40 -0400
From: "Heimberg, Jim" <[email-masked]>
Subject: RE: Global unique identifier
To: "'Denis Pinkas'" <[email-masked]>, Anders Rundgren <[email-masked]>
Cc: [email-masked]

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [email-masked]
Subject: Global unique identifier

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders

Date: Thu, 13 Apr 2000 00:35:27 -0700
From: Ed Gerck <[email-masked]>
Subject: Newsletter on Internet voting, privacy and security issues
To: "[email-masked]" <[email-masked]>

List:

I would like to extend an invitation to the PKIX list to read "The 
Bell" -- the first newsletter entirely dedicated to Internet voting and 
collaborative decision-making in Internet protocols (including the use 
of digital certificates and the resulting security/privacy concerns from
potentially non-anonymous voting). Electronic and hard copy subscriptions 
are available at www.thebell.net.

Safevote [1] is sponsoring the newsletter as an open forum.  Regarding 
the name "The Bell", the idea was to use the image of a bell because 
mission bells were used in colonial California for telling time, 
announcing events, and for passing on news from one city to another. 
This newsletter intends to serve similar purposes and is also a public 
service open and free for all who may want it.

With monthly 16-page issues, the "The Bell" will focus on privacy, 
security and technology used in Internet voting. 

In Internet tradition, the newsletter is available free over the 
Internet (PDF format), or at an annual cost of $30 for first class 
mail delivery in hard copy.   The first issue contains an extensive 
marketing study of the year 2000 U.S. public elections market - a 
study that will be serialized in upcoming issues.  It also includes 
an article on today's public voting systems used in the United States 
by election expert Roy G. Saltman and an essay by myself outlining the
need for a strong separation between identification and authentication
in order to ensure fair Internet voting protocols.

Internet voting and its potential impact on society will increasingly
call upon us to understand and keep abreast of the latest developments 
in various fields of work. As a developer in this market, I see a 
widening gap between the 100-year-old voting technologies in use today 
and what Internet voting needs to take into account. The Bell is 
dedicated to help fill this gap -- perhaps with your help as well.

Cheers,

Ed Gerck

[1] Safevote (www.safevote.com) is a founding member of the Internet 
Voting Technology Alliance (www.ivta.org) and develops OEM (Original 
Equipment Manufacturer) systems for Internet voting, polling, public 
elections, bidding, consensus assessment and other Internet decision-
making applications. The Bell is edited at Safevote. The May 2000 issue 
is now available at the "The Bell" Web site, www.thebell.net

Date: Thu, 13 Apr 2000 14:44:21 +0900
To: [email-masked], [email-masked], [email-masked]
From: Takuya INOUE <[email-masked]>

subscribe

Date: Wed, 12 Apr 2000 18:42:10 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: document status portion of the minutes, from Warwick
Cc: [email-masked]

Paul,

You're right.  We'll fix the document status part of the minutes.

Steve

Date: Wed, 12 Apr 2000 15:29:13 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: document status portion of the minutes, from Warwick

At 06:02 PM 4/12/00 -0400, Stephen Kent wrote:
>ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
>         - Finished - will be folded into Revised Part 1

This doesn't match what we agreed to in the meeting, as is reflected in 
Steve's minutes. The words from the minutes are "There was prior agreement 
to move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to remove 
section 7 and combine it with the ECDSA document to create a new PKIX 
document, devoted to algorithms."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 12 Apr 2000 18:02:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: document status portion of the minutes, from Warwick

--============_-1256545091==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)
- Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
- Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
- Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
- Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
- Approved as Proposed Standard
OCSP (RFC 2560)
- Approved as Proposed Standard
CMP (RFC 2510)
- Approved as Proposed Standard
CRMF (RFC 2511)
-Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
	- Approved as Informational RFC
CMC (draft-ietf-pkix-cmc-05.txt)
- Approved to Proposed - In RFC Editor processing
Diffie-Hellman POP (draft-ietf-pkix-dhpop-02.txt)
	- In the AD's hands?

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-01.txt)
ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
	- Finished - will be folded into Revised Part 1
Revised CMP (draft-ietf-pkix-rfc2510bis.00)
Qualified Certificates (draft-ietf-pkix-qc-03.txt)
	- WG Last Call pending closure
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-06.txt)
	- Approved by WG - ready for forwarding to IESG
Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)
Attribute Certificate Profile for Authorization 
(draft-ietf-pkix-ac509prof-02.txt)
Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)
DCS (draft-ietf-pkix-dcs-04.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-02.txt)
OCSP Extensions (draft-ietf-pkix-ocspx.txt) - posted on IMC site
CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)
CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

--============_-1256545091==_ma============
Content-Type: text/enriched; charset="us-ascii"

<fontfamily><param>Courier_New</param><bigger>PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)

- Approved as Proposed Standard

KEA Algorithms for Profile (RFC 2528)

- Approved as Informational RFC

HTTP/FTP Operations (RFC 2585) 

- Approved as Proposed Standard

LDAP V2 Operational Protocols (RFC 2559)

- Approved as Proposed Standard

LDAP V2 Schema (RFC 2587)

- Approved as Proposed Standard

OCSP (RFC 2560)

- Approved as Proposed Standard

CMP (RFC 2510)

- Approved as Proposed Standard

CRMF (RFC 2511)

-Approved as Proposed Standard

Certificate Policy/Practices Guideline (RFC 2527)

	- Approved as Informational RFC

CMC (draft-ietf-pkix-cmc-05.txt)

- Approved to Proposed - In RFC Editor processing

Diffie-Hellman POP (draft-ietf-pkix-dhpop-02.txt)

	- In the AD's hands?

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-01.txt)

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)

	- Finished - will be folded into Revised Part 1

Revised CMP (draft-ietf-pkix-rfc2510bis.00)

Qualified Certificates (draft-ietf-pkix-qc-03.txt)

	- WG Last Call pending closure

PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)

Time Stamp (draft-ietf-pkix-time-stamp-06.txt)

	- Approved by WG - ready for forwarding to IESG

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization
(draft-ietf-pkix-ac509prof-02.txt)

Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-04.txt)

Simple Certificate Validation Protocol (SCVP)
(draft-ietf-pkix-scvp-02.txt) 

OCSP Extensions (draft-ietf-pkix-ocspx.txt) - posted on IMC site

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)
</bigger></fontfamily>

--============_-1256545091==_ma============--

Date: Wed, 12 Apr 2000 13:40:53 -0700
To: "Christopher Williams" <[email-masked]>, "PKIX Mailing List" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Format of error text

At 05:53 PM 4/12/00 +0100, Christopher Williams wrote:
>The specification states:
>
>"-- text encoded as UTF-8 String [RFC2279] (note:  each UTF8String
>   -- SHOULD include an RFC 1766 language tag to indicate the
>   -- language of the contained text -- see [RFC2482] for details)"
>
>Does this mean something like the following:
>
>"<en-uk> Unexpected PKI message"?

The actual octets in the UTF-8 string would be:

f3a081a5 f3a081ae f3a080ad f3a081b5 f3a081ab 
556e6578   ....................Unex
70656374 65642050 4b49206d 65737361 6765                pected PKI message

Having said this, I think that the SHOULD in the above section is probably 
overstated. I say this as someone who previously lobbied for language 
tagging. The general feeling about language tags these days is that they 
are only needed for machine processing, such as text-to-speech synthesizers 
and spelling checkers. It might be good if draft-ietf-pkix-rfc2510bis 
changed this from a SHOULD to a MAY.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>, [email-masked]
Subject: SNACC ASN.1 Freeware Release & Mail List
Date: Wed, 12 Apr 2000 16:27:03 -0400

All,

J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
delivered an enhanced version of the freeware SNACC v1.3 rev 0.07 Abstract
Syntax Notation.1 (ASN.1) Compiler and Library.  In past releases, VDA
enhanced the C++ version of the SNACC library to implement the Distinguished
Encoding Rules (DER).  In the new release, VDA enhanced the C and C++
versions of the SNACC library to support PrintableString, TeletexString,
NumericString, IA5String, 
VisibileString, BMPString, UniversalString and UTF8String character string
types.  We added an optional function to SNACC that can be used to convert
ASN.1 OCTET STRINGs to single- or multi-byte character strings (as
appropriate).  This is needed to support the RFC 2459 PKIX requirements.
The SNACC enhancement is completely optional and does not impact existing
code that uses SNACC.  The SNACC library decodes an object as it always has.
If the application/library needs the ASN.1 OCTET STRINGs converted to
character strings, then it calls the new SNACC function/class to perform the
conversion.  If an application/library does not need the ASN.1 OCTET STRINGs
converted, then it does not need to call the conversion function/classes and
can use the SNACC-generated structures/classes as always.  

The VDA-enhanced SNACC compiler and C++ library is available along with the
S/MIME Freeware Library (SFL)
<http://www.armadillo.huntsville.al.us/software/smime> that uses SNACC to
implement the S/MIME v3 set of specifications.  The snacc1_6VDA.zip file
contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code
compilable for Unix and MS Windows NT/95/98/2000.   

The VDA-enhanced SNACC C library is available along with the freeware
Certificate Management Library (CML)
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html)> that
uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459.  The
CML17sr.tar.Z file includes the source code for the CML and VDA-enhanced
SNACC C library compilable for Unix and MS Windows NT/95/98/2000. 

We plan to consolidate the enhancements made by VDA to the C and C++
versions of the SNACC source code into a single baseline that can be
delivered in a single tar/zip file.

In the new release, we also corrected a bug in the DEC_LOAD_ANYBUF macro.
We changed "bytesDecoded" to "bytesDecodedXX" to avoid conflict other SNACC
uses of the "bytesDecoded" variable.  We also enhanced the AsnOid method so
that it accepts a dynamic number of components within an object identifier. 

SNACC implements the majority of ASN.1 encoding/decoding rules.  SNACC does
not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to be
used to produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note that
many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1
syntax modules which can be directly compiled using SNACC.

The SNACC ASN.1 library is totally unencumbered as stated in the SFL Public
License.  All source code for the VDA-enhanced SNACC software is being
provided at no cost and with no financial limitations regarding its use and
distribution.  Organizations can use the VDA-enhanced SNACC software without
paying any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established a SNACC web page
<http://www.imc.org/imc-snacc/>.  The IMC has also established a SNACC mail
list which is used to: distribute information regarding SNACC releases;
discuss SNACC-related issues; and provide a means for SNACC users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-snacc mail list is at the IMC web site listed above.

VDA welcomes all feedback regarding the VDA-enhanced SNACC software.  If
bugs are reported, then VDA will investigate each reported bug and, if
required, will produce a patch or an updated release of the software to
repair the bug.  We recommend that comments should be sent to the imc-snacc
mail list.  We will respond to all messages on that list.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: v1.7 Certificate Management Library & Mail List 
Date: Wed, 12 Apr 2000 16:23:43 -0400

All,

J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
delivered the freeware Version 1.7 Certificate Management Library (CML)
software and Application Programming Interface (API).  An enhanced version
of the SNACC ASN.1 C library has been delivered with the v1.7 CML.  The v1.7
CML and enhanced SNACC source code is available from the Fortezza
Developer's CML Page
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html>.  

The CML implements the 1997 X.509 certification path processing rules and
meets SDN.706 requirements.  It (optionally) provides local cache management
functions and (optionally) obtains data objects using LDAP v2.  It can
(optionally) be used in conjunction with the v1.31 Certificate Path
Development Library (CPDL) developed by CygnaCom Solutions to provide robust
certification path building capabilities such as using cross certificates.
The CML has been used to validate X.509 Certificates and Certificate
Revocation Lists (CRL) signed using Digital Signature Algorithm (DSA) and
RSA.   

The v1.7 CML includes the following enhancements (compared with the v1.6 CML
release):

1) Tested with the SNACC C++ library, Crypto Token Interface Libraries
(CTIL) and LibCert Dynamically Linked Libraries (DLL) delivered with the
v1.6 S/MIME Freeware Library (SFL) available from the Fortezza Developer's
S/MIME Page <http://www.armadillo.huntsville.al.us/software/smime>.

2) Enhanced CML API and software to add function to validate generic signed
data (using SIGNED macro).

3) Added functionality to set LDAP settings, trusted certificates, and a
validated public key cache on a per session basis.

4) Fixed uninitialized pointer problem on Extended Key Usage extensions, and
the freeing of the Extended Key Usage extension.

5) Fixed memory leak in freeing of a EncObject_LL.

6) Fixed memory leak in asn-any.c (line 175).

7) Fixed memory leaks in  CMU_GetDistPts().

8) Added the UID attribute to SNACC library.

9) Enhanced the CMU_FilterRemoteCertsList() function to perform certificate
filtering after LDAP retrieval.

10) Enhanced the setting of the CRL/ARL type in the CML provided callback
function, and set correctly the location flag in the CML provided callback.

11) Corrected the CRL Issuing Distribution Point processing logic.

12) Enhanced CML to automatically search the directory using LDAP for a
current certificate or CRL when the local CRL or Certificate has expired, if
the application has specified "search until found".

13) Tested CML with C and C++ versions of SNACC ASN.1 library that have been
enhanced to support PrintableString, TeletexString, NumericString,
IA5String, VisibileString, BMPString, UniversalString and UTF8String
character string types.  An optional function was added to SNACC to convert
ASN.1 OCTET STRINGs to single- or multi-byte character strings (as
appropriate).  The C version of the enhanced SNACC library is included in
the CML17sr.tar.Z file.  The C++ version of the enhanced SNACC library is
available with the SFL.

The following v1.7 CML files are available from the Fortezza Developer's CML
Page:
CMLv17win.zip: Windows DLLs 
CML17so.tar.Z: Solaris Libraries 
CML17sr.tar.Z: Source for CML and SNACC C library, includes Windows project
files 
CMv1_7api.doc, CMv1_7api.pdf: MS Word and Adobe PDF versions of v1.7 CML API
document
cml17data.zip: test certs used to test the CML 
readme.txt: Instructions for installing and using the CML

VDA welcomes all feedback regarding the CML software and documents.  If bugs
are reported, then VDA will investigate each reported bug and, if required,
will produce a patch or an updated release of the software to repair the
bug.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  VDA is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.7 CML uses the VDA-enhanced SNACC v1.3 ASN.1 Library to encode/decode
objects.  VDA has successfully tested the v1.7 CML with the SNACC and CTIL
DLLs delivered in conjunction with the v1.6 SFL.  Source code for the
VDA-developed CTILs is available from the Fortezza Developer's S/MIME Page.
The actual crypto libraries are not provided with the CML or SFL.  They must
be independently obtained from the appropriate source.  

The v1.7 CML can be used in conjunction with the v1.31 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML17sr.tar.Z file includes the CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

Further enhancements, ports and testing of the CML are still in process.
Further releases of the CML will be provided as significant capabilities are
added.  

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml/>.  The IMC has also established a CML mail list
which is used to: distribute information regarding CML releases; discuss
CML-related issues; and provide a means for CML users to provide feedback,
comments, bug reports, etc.  Subscription information for the imc-cml
mailing list is at the IMC web site listed above.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[email-masked]
============================================ 

Date: Wed, 12 Apr 2000 15:47:26 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: minutes & slides
Cc: [email-masked]

Peter,

>  > Time Stamping Protocol  (D. Pinkas-Bull)
>  > In addition to minor fixes and syntax changes to simplify the ASN.1,
>  > some changes were made to accommodate requests from an ISO committee
>  > that is also working on time stamping and wanted both protocols to be
>  > closely aligned. The changes made in TSP accommodated most but not
>  > all of the requests. A news version of the document will be issued
>  > soon, while we await a response from ISO re the current set of
>  > changes. (See slides for more details.)
>
>The changes made to the protocol also include ASN.1 changes with
>the goal to MINIMISE the encoding length (getting rid of unnecessary
>tagging).

I'll update the minutes accordingly.

>  >
>  > DVCS  (P. Sylvester-EdelWeb)
>  > This is the current version of the document that began as a notary
>  > protocol from Adams & Zuccherato, and then became the data
>  > certification service protocols, before editorial responsibility
>  > shifted. Motivation for this protocol is to support a central
>  > infrastructure for document security management, e.g., in an intranet
>  > or extranet environment, or for other long term secure document
>  > management. The protocol is designed to enable delegation of
>  > signature verification, notarization, and even certificate use
>  > controls to a server (vs. and end system). The presentation included
>  > a number of scenarios motivating the need for the protocol and its
>  > features. The question arises whether the complex document management
>  > system features described here is really an infrastructure component
>  > within the purview of this WG or it is more of an application? (See
>  > slides for more details.)
>
>This question does NOT arise:
>
>  >From goals and milestones of the working group:
>
>Dec 99 : Complete data certification document
>
>The question was: Are 31 pages too complicated to read for people
>(just 10 pages more than in time stamping).
>
>I would not be surprised if someone thinks that
>31 are definetely not enough to describe a 'complex' protocol.

If the protocol has become very complex because it attempts to embody 
features needed to support a rather complete document management 
scenario, then it may have crossed the boundary from infrastructure 
protocol to application protocol.  The WG will have to decide on this 
issue, after reviewing the document.

Steve

From: [email-masked]
To: "Christopher Williams" <[email-masked]>
cc: "PKIX Mailing List" <[email-masked]>
Date: Wed, 12 Apr 2000 15:01:03 -0400
Subject: Re: Getting CA capabilities

     Actually, there's one more reason I can think of.  A CA's software can
be upgraded between versions, adding new capabilities (perhaps support for
a new digest algorithm) and its certificate would not usually change.  So
for a variety of reasons, a messaging interface is better than a
certificate for capabilities.  If a non-messaging interface were used,
something that might work would be an AIA value pointing at the URI where
capabilities could be downloaded or checked.
     However, for extensibility reasons, the list of capabilities returned
should probably be a set or sequence of object ID's rather than a bit
string.
     On your other issue, since HMAC-SHA1 is already mandatory to implement
in RFC 2510 and is the only MAC algorithm which is, why rule out the use by
bilateral agreement of other algorithms?  In practice, will clients which
are intended to be used with multiple vendors' server dare to use anything
else by default?

          Tom Gindin

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Key generation parameters response
Date: Wed, 12 Apr 2000 19:51:35 +0100

One of the GeneralInfo types in the PKIX specification is a key generation
parameters response.  Exactly what would be the key generation parameters
for, say, RSA, DSA and Diffie-Hellman?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Format of error text
Date: Wed, 12 Apr 2000 17:53:30 +0100

The specification states:

"-- text encoded as UTF-8 String [RFC2279] (note:  each UTF8String 
  -- SHOULD include an RFC 1766 language tag to indicate the 
  -- language of the contained text -- see [RFC2482] for details)"

Does this mean something like the following:

"<en-uk> Unexpected PKI message"?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: Peter Sylvester <[email-masked]>
Date: Wed, 12 Apr 2000 20:47:42 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: minutes & slides

> Time Stamping Protocol  (D. Pinkas-Bull)
> In addition to minor fixes and syntax changes to simplify the ASN.1, 
> some changes were made to accommodate requests from an ISO committee 
> that is also working on time stamping and wanted both protocols to be 
> closely aligned. The changes made in TSP accommodated most but not 
> all of the requests. A news version of the document will be issued 
> soon, while we await a response from ISO re the current set of 
> changes. (See slides for more details.)

The changes made to the protocol also include ASN.1 changes with
the goal to MINIMISE the encoding length (getting rid of unnecessary
tagging). 

> 
> DVCS  (P. Sylvester-EdelWeb)
> This is the current version of the document that began as a notary 
> protocol from Adams & Zuccherato, and then became the data 
> certification service protocols, before editorial responsibility 
> shifted. Motivation for this protocol is to support a central 
> infrastructure for document security management, e.g., in an intranet 
> or extranet environment, or for other long term secure document 
> management. The protocol is designed to enable delegation of 
> signature verification, notarization, and even certificate use 
> controls to a server (vs. and end system). The presentation included 
> a number of scenarios motivating the need for the protocol and its 
> features. The question arises whether the complex document management 
> system features described here is really an infrastructure component 
> within the purview of this WG or it is more of an application? (See 
> slides for more details.)

This question does NOT arise: 

>From goals and milestones of the working group: 

Dec 99 : Complete data certification document

The question was: Are 31 pages too complicated to read for people
(just 10 pages more than in time stamping).
 
I would not be surprised if someone thinks that
31 are definetely not enough to describe a 'complex' protocol.

> SCVP
> OCSPX
One WG member mentioned thanked the presentators for giving
two slightly differing presentations for a subset of a more
general service that is already described in another document
(namely DVCS). 

This doesn't mean that I am in favour or not of what is supposed to
be proposed by SCVP or OCSPX ... or CERTDIST, ...

Regards
Peter

Date: Wed, 12 Apr 2000 12:15:45 -0400
From: Sam Schaen <[email-masked]>
Organization: The MITRE Corporation
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Global unique identifier

Christopher Williams wrote:
> 
> There aren't many details about a person that can be assumed to be constant
> (not even his / her name).  Certainly not his subject name as that
> presumably changes when the person changes job.  The US has a social
> security number; other countries have similar schemes (I have a unique
> National Insurance number).  If there are privacy issues surrounding the use
> of these values, use a SHA-1 hash of the value instead.

Since the number of possible values is limited (e.g., 10**9 for U.S.
Social Security Number), it is feasible to precompute the hashes for all
possibilities and do a lookup.  So privacy is minimal.  On the other
hand, few people believe the SSN is very private these days.

Sam Schaen
MITRE Corp.

Date: Wed, 12 Apr 2000 12:02:10 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Global unique identifier

>>>>> "Christopher" == Christopher Williams <[email-masked]> writes:

 Christopher> There aren't many details about a person that can be
 Christopher> assumed to be constant (not even his / her name).
 Christopher> Certainly not his subject name as that presumably
 Christopher> changes when the person changes job.  The US has a
 Christopher> social security number; other countries have similar
 Christopher> schemes...

Just to repeat what has been said before:

a. The US SSN is *not* a globally unique identifier.  It is an "almost 
always unique identifier".

b. The US SSN is not necessarily constant for a given person.  There
are conditions under which a person can obtain a new SSN.  Given the
increased use of the SSN for dubious purposes (e.g., for insurance ID
numbers, student ID numbers, and other things of questionable
legality) the incentive for SSN abuse is increasing dramatically.
This in turn will cause the rate of SSN change to increase (since SSN
abuse is one of the recognized grounds for getting a new one).  (FYA,
having an SSN that contains the string "666" is another.)

	paul

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Re: Global unique identifier
Date: Wed, 12 Apr 2000 16:58:54 +0100

There aren't many details about a person that can be assumed to be constant
(not even his / her name).  Certainly not his subject name as that
presumably changes when the person changes job.  The US has a social
security number; other countries have similar schemes (I have a unique
National Insurance number).  If there are privacy issues surrounding the use
of these values, use a SHA-1 hash of the value instead.

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Re: Getting CA capabilities
Date: Wed, 12 Apr 2000 16:49:39 +0100

Having thought about it, the Authority Information Access extension is not
the correct place for CA capability information:

1. It's a kludge
2. It's part of a separate (if related) specification; the PKIX
specification is where the issue needs to be addressed.
3. As Robert Moskovitz pointed out, you might not get the CA certificate
until the initialization response.  The initialization request can contain a
request for a server-generated encryption key.

Having the capabilities expressed in a policy document is also not the place
for it.  A human can read the document, but a machine cannot.  I know you
can express policies with ObjectIdentifiers, but this requires a client to
have intimate knowledge of the server - a hypothetical universal PKIX client
program could not understand this information.

With the current specification we can ask a CA what key types it supports
(i.e. we can tell from this if DSA is supported), but we can't ask whether
that CA will generate a DSA key on our behalf and then store it for us.
It's not really an error to ask a CA which doesn't support key generation to
generate a key if you don't know about it in advance, but presumably the CA
has to return something like badRequest.

I think a new GeneralInfo type should be devised.  The value could be a BIT
STRING whose contents indicate a mask of capabilities, e.g. bit 1 could mean
"supports key generation", bit 2 means "supports key archival and recovery",
etc.

Beyond the required capabilities of a compliant information, a lot of the
PKIX specification is pretty esoteric and may actually never be encountered
in a real world implementation.  A method of exchanging capability
information would save implementors from having to code for every
eventuality.

On the subject of making implementors' lives easier, is there any chance of
specifying SHA-1 / HMAC-SHA-1 as the ONLY permissible algorithms for a
password based MAC?  I know the aim of the specification is that it should
be as general as possible, but sometimes it's good to be strict.

----- Original Message -----
From: Robert Moskowitz <[email-masked]>
To: Oscar Jacobsson <[email-masked]>; Christopher Williams
<[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Sent: 11 April 2000 13:39
Subject: Re: Getting CA capabilities

> At 01:44 PM 4/11/2000 +0200, Oscar Jacobsson wrote:
> >Christopher Williams wrote:
> > > There does not seem to be any way for an EE to obtain details of
certain CA
> > > capabilities, e.g. whether the CA supports key generation, whether the
CA
> > > supports key archival and retrieval, etc. unless the EE has intimate
> > > knowledge of the CA.  Should the EE's client software be able to
obtain
> > > programmatically details about the server software's capabilities?  Is
this
> > > a possible GeneralInfo type?
> >
> >Would this not be best handled via the Authority Information Access
> >extension? RFC 2459 sure does make it sound like a prime candidate for
> >distributing such information:
> >
> >"The authority information access extension indicates how to access CA
> >information and services for the issuer of the certificate in which
> >the extension appears. Information and services may include on-line
> >validation services and CA policy data."
>
> But that is after the fact.  In CMP, you do not get the CA's cert until
you
> get your Initialization Response.
>
> As I pointed out to Chris in private, CMP has an out-of-band I&A process
> for IR's shared secret.  During this process, all CA policy can be handed
> to the EE.
>
> Interestingly, if you were to want to use a QC cert to sign a CP in place
> of the out-of-band I&A and IR, then you DO need a programatic way for the
> EE to get the policy.
>
> To this extent, I do not believe we KNOW all the items and values that
> would be expressed in a policy.  Or at least I have not seen any such
> document.  So for an EE programmer to deal with this, we first need to
> define what IS configurable policy, or at least those policy items that
> impact EE behaviour.
>
>
>
> Robert Moskowitz
> ICSA
> Security Interest EMail: [email-masked]
>
>

From: [email-masked]
To: Robert Moskowitz <[email-masked]>
cc: Anders Rundgren <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 12 Apr 2000 11:16:18 -0400
Subject: RE: Global unique identifier

Robert Moskowitz <[email-masked]> on 04/12/2000 10:42:00 AM

To:   Anders Rundgren <[email-masked]>, "'Denis Pinkas'"
      <[email-masked]>
cc:   "[email-masked]" <[email-masked]>
Subject:  RE: Global unique identifier

At 03:29 PM 4/12/2000 +0200, Anders Rundgren wrote:

>Essentially only one per country at maximum.   Companies etc. and
commercial
>issuers like VerySign will use CA-specific naming domains I suppose?

No.  Get real.

A GUI would perforce be the IssuerName concatenated with the SubjectName.

[Tom Gindin]   A pre-existing GUI would not have to be based on the
IssuerName, nor would it necessarily contain the entire subject name.  It
could be (in the USA) a Social Security number (country + ID value) or an
employee ID (organization + ID value) - although Social Security numbers
might get banned by privacy legislation.  Only if the CA itself assigned
the GUI would the IssuerName be a mandatory component.

I can even seen problems there, wtih WTO or WIPO hving to deal with suits
and counter suits between CAs that use the same name.  At least with DNS we
stopped the independent root efforts.

[Tom Gindin]   Identical DN's for independent issuers would cause very
severe problems with the current standards, starting with CMS SignerInfo.
These proposals would not introduce any new limitations in that respect.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Wed, 12 Apr 2000 10:42:00 -0400
To: Anders Rundgren <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: RE: Global unique identifier
Cc: "[email-masked]" <[email-masked]>

At 03:29 PM 4/12/2000 +0200, Anders Rundgren wrote:

>Essentially only one per country at maximum.   Companies etc. and commercial
>issuers like VerySign will use CA-specific naming domains I suppose?

No.  Get real.

A GUI would perforce be the IssuerName concatenated with the SubjectName.

I can even seen problems there, wtih WTO or WIPO hving to deal with suits 
and counter suits between CAs that use the same name.  At least with DNS we 
stopped the independent root efforts.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Global unique identifier
Date: Wed, 12 Apr 2000 15:29:08 +0200

Denis,

>In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
>each subject entity certified by the one CA as defined by the issuer
>name field". There is no requirement to make the DN unique across
>multiple CAs. 

Agreed, and I think the definition is OK.

>Adding this requirement would either break RFC 2459 or build
>something very different. Today, when a DN is used, it is a DN from
>a given CA.

Unless they conform to an "external naming/identification scheme".  But that does not
break 2459, it just extends it.

<snip>

>Now let us make the assumption that we introduce an explicit naming
>domain information (or naming authority information) in some form of
>name. Note that this topic does not apply only to the permanent
>identifier but could apply as well to the DN: this is why it should
>be discussed on a different thread. 

I definitely agree that this apply to the entire DN.

>As a conclusion, this particular aspect should be discussed on a
>separate thread (I have called it "Global unique identifier" but you
>may use any other name you prefer, as long as it is not "permanent
>identifier").

New tread? Nema problema!  Regarding global unique identifier I would prefer
that the external naming domains where registered centrally as they will be few.

Essentially only one per country at maximum.   Companies etc. and commercial
issuers like VerySign will use CA-specific naming domains I suppose?

Anders
,

Date: Wed, 12 Apr 2000 15:03:42 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Anders Rundgren <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Global unique identifier

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and (implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders

From: Anders Rundgren <[email-masked]>
To: Stephen Kent <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Permanent identifiers in QC
Date: Wed, 12 Apr 2000 12:55:26 +0200

Denis,
<snip>
>Please, do not make the story more complicated than requested. The
>permanent identifier is a name of the subject, unique within the
>issuer domain, that is not reused over time for another subject. The
>name is only unique within the issuer domain (i.e. CA). Making the
>name unique across different CAs would break the current PKIX model. 

The requirement stated by Tom is very valid (I have raised it on this list a countless number of times)
and applies 100% to what is supposed to be happening any old day here in Sweden. 
I.e. a number of competing CAs issue certificates to a Naming Domain they do not govern themselves.
These identity certificates are supposed to be totally interchangeable as their physical counterparts
have been the last 30 years or so.  By the use of a permanent ID and (implicit) naming domain.

I.e. any improvement or addition to QC must address the naming domain question as well.
Or as Tom prefers.  The naming authority. 

Anders

Date: Wed, 12 Apr 2000 12:31:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Permanent identifiers in QC

Steve, Anders, Stefan, Tom, Russ, and the WG, 

I will use the response from Steve to comment and add a few things
captured in other E-mails.

Mike said: " I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  <
snip>  That is the task of other WGs. " 

Russ said something similar: "If some Internet application needs a
permanent identifier, then the needy application should specify it".

The right answer has been given by Steve: " ... if there is a need
for such forms of IDs, and if they span multiple applications, then
we could reasonably define them in PKIX."

So the basic question is whether there is a need for such form of
permanent ID. Some arguments were raised whether the need was for
acces control purposes only or also for non-repudiation purposes. No
one is disputing that it is usefull for access control purposes. I
would like to mention that this OPTIONAL feature MAY also be usefull
for non-repudiation purposes. A non repudiation service may be used
in the context of a transaction. It may be usefull to be able to
relate different transactions to the same individual, *even when the
name (i.e. DN) of the individual changes*. The current DN cannot be
used for such a purpose. A permanent identifier allows to support
that feature. 

At the meeting we said, as Stefan reported: " the decision whether
or not to include this name form in QC should be taken to the list".
This is correct (and not reflected in the draft minutes just
received). :-(

A basic question is whether the permanent identifier should be
described in the son of RFC 2459 or in QC. Let us forget the
technical aspect for a moment and face the procedural aspect. Let us
suppose that it is not defined in QC, but in the son of RFC 2459.
Since QC refers to RFC 2459, not the son of RFC 2459, even if it is
described there it will not apply, i.e. it will not be a possible
feature of QC. 

We should include it in QC now, because there is a need to define
what is (or what is not) a QC within a couple of months. If this is
not included, it will not be possible to people to issue QCs with
permanent identifiers, even if the feature is described in another
separate document. Otherwise it would mean that in order to conform
to the European Directive, you would have to consult two separate
RFCs, which would be a little odd or bizare.

Now I would like to come back to the technical aspect. Stefan said:
 
" 1) Adding this name form would add confusion to the QC
specification since it would overlap use of serialNumber in the DN." 

If we are not careful with the text defining what a serial Number
is, Stefan is right when he says that some confusion might be
possible. But is it easy to fix it. The permanent identifier can
include ANY attribute. Currently the definition of serialNumber
mandates its use only in the DN. We could extend the definition (as
I have proposed) and its meaning when it is included either in the
DN or in the permanent identifier.

> Tom,
> 
> >      I do not understand why permanent identifiers would be much less
> >useful in a non-repudiation situation than in an access control situation.
> >A third-party verifier is just as interested in distinguishing between two
> >individuals named "John Smith" to decide whether the subject of the
> >certificate used to sign a document in the past is the same person as the
> >relying party claims it is as an access control system would be in whether
> >the certificate subject is the owner of account "jsmith".  It is true that
> >transaction volumes for NR verification would probably be low enough that
> >manual techniques like checking what identification was presented to the CA
> >or RA could be used in the absence of a permanent identifier, and that the
> >verifier might wind up having to check the CA's records anyway, especially
> >if certification masquerade is claimed.  However, access control systems
> >may not think that a permanent ID match from a cross-certified CA is
> >absolute proof of identity either, and might prefer storing specific
> >certificate ID's.
> 
> I understand your point that under some circumstances it may be
> desirable to be able to determine if two different certs, involved in
> signing two different objects, are the same individual.  But that
> certainly is an extension of the basic non-repudiation service, which
> focuses on whether a given signature for a signed object is valid,
> relative to a set of rules re certificate issuance, path validation,
> revocation, etc.  

I do not see this as an extension. One way to look at the problem is
to consider at a broad level the difference between the DN and the
permanent identifier.

The permanent identifier is basically "machine processable" while
the DN is mainly "human processable". The permanent identifier does
not necessarilly allow a human being to identify directly the
individual, e.g. a social security number for an individual or an
employee number (associated with a company name) for an employee.

The DN allows a better direct identification (if a pseudonym is not
used and if there are no homonyms). The serialNumber when used in
conjunction with a DN does not allow a better identification, it
only allows to differentiate between two homonyms, i.e. John Smith
22 and John Smith 41. Some "other (undefined) means" are needed to
tell which John Smith you are looking for.

Let me present two simple scenarios which explain how the permanent
identifier might be used in the context of non-repudiation.

1) The first time a transaction is being received by a transaction
system, the DN is looked at in conjunction with some "other means"
(maybe using some human intelligence). If it is found acceptable,
then the permanent identifier can be used to link future
transactions from the same individual, even if the DN changes.

2) When a user registers to a transaction system, it presents his
certificate. Once the certificate is accepted, then the permanent
identifier is used to accept and link subsequent transactions, even
if the DN changes. 
 
> We probably ought not add features to QC certs to
> address increasingly more complex scenarios, vs. the general case NR
> scenarios that the QC document editor has established as the scope of
> that effort.  

> For example, Denis's proposal does not ensure that one
> can compare the IDs in the new name form when they are issued under
> two different CAs. I can imagine applications where that might be an
> important feature, but that does not mean that we ought to define a
> construct for supporting such a facility.

Please, do not make the story more complicated than requested. The
permanent identifier is a name of the subject, unique within the
issuer domain, that is not reused over time for another subject. The
name is only unique within the issuer domain (i.e. CA). Making the
name unique across different CAs would break the current PKIX model. 

Denis

> In another example, the PKIX WG was treated to an impressive
> presentation in Adelaide on a protocol suite that supports very
> complex document management applications. It probably subsumes the
> functions of SCVP, OCSP, and maybe parts of CMP!  However, that
> protocol is probably too elaborate and too focused on a specific
> application context to match the WG charter of standardizing generic,
> infrastructure services and data formats.
> 
> Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Tue, 11 Apr 2000 20:13:25 -0400
Subject: Re: Permanent identifiers in QC

     I am responding to some of your replies below.  However, if an
OTHER-NAME is more appropriate for this purpose than a QC statement, the
following ASN.1 definitions for such an OTHER-NAME might make it clear what
I am suggesting:

authorityAssignedID OTHER-NAME ::= { AuthorityAssignedID IDENTIFIED BY
                    id-pkix-authorityAssignedID }
AuthorityAssignedID ::= SEQUENCE   {
     authority GeneralName,
     ID        DirectoryString
     }

CAAssignedID OTHER-NAME ::= { IssuerAssignedID IDENTIFIED BY
                    id-pkix-CAAssignedID }
IssuerAssignedID    ::= DirectoryString

     National identities can easily be represented by an
authorityAssignedID with the authority specified by a DN containing only a
country attribute.
     The first of these two forms has quite general use, and the only
application the second is specific to is the CA itself.

          Tom Gindin

Stephen Kent <[email-masked]> on 04/11/2000 04:01:23 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: Permanent identifiers in QC

Tom,

>      I do not understand why permanent identifiers would be much less
>useful in a non-repudiation situation than in an access control situation.
>A third-party verifier is just as interested in distinguishing between two
>individuals named "John Smith" to decide whether the subject of the
>certificate used to sign a document in the past is the same person as the
>relying party claims it is as an access control system would be in whether
>the certificate subject is the owner of account "jsmith".  It is true that
>transaction volumes for NR verification would probably be low enough that
>manual techniques like checking what identification was presented to the
CA
>or RA could be used in the absence of a permanent identifier, and that the
>verifier might wind up having to check the CA's records anyway, especially
>if certification masquerade is claimed.  However, access control systems
>may not think that a permanent ID match from a cross-certified CA is
>absolute proof of identity either, and might prefer storing specific
>certificate ID's.

I understand your point that under some circumstances it may be
desirable to be able to determine if two different certs, involved in
signing two different objects, are the same individual.  But that
certainly is an extension of the basic non-repudiation service, which
focuses on whether a given signature for a signed object is valid,
relative to a set of rules re certificate issuance, path validation,
revocation, etc.  We probably ought not add features to QC certs to
address increasingly more complex scenarios, vs. the general case NR
scenarios that the QC document editor has established as the scope of
that effort.  For example, Denis's proposal does not ensure that one
can compare the IDs in the new name form when they are issued under
two different CAs. I can imagine applications where that might be an
important feature, but that does not mean that we ought to define a
construct for supporting such a facility.

[Tom Gindin] My major point is that this facility is no more beyond the
core scope of NR than beyond that of authentication.  If Denis' proposal is
the one in his posting of March 15, it covers one of the three cases I
proposed in my postings of March 30-31 - the case I described as
id-qcs-CALocal.  The  proposed identifier assignment authority is more
general and would enable comparisons for equality across CA's.  The
heuristic is: two such identities match if both the authorities and the
identifiers match, and do not match otherwise.  The issuer name does not
enter into the comparison in this case.  In the special case where the
issuer is defined to be the assignment authority (which I assigned its own
semantics identifier), the identities cannot be compared across CA's.

In another example, the PKIX WG was treated to an impressive
presentation in Adelaide on a protocol suite that supports very
complex document management applications. It probably subsumes the
functions of SCVP, OCSP, and maybe parts of CMP!  However, that
protocol is probably too elaborate and too focused on a specific
application context to match the WG charter of standardizing generic,
infrastructure services and data formats.

[Tom Gindin] A requirement for a name form consisting of an assignment
authority and an identifier seems to be fairly general.  It has come up
both in the QC discussions and for access control.

Steve

Date: Tue, 11 Apr 2000 17:26:15 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: minutes & slides

--============_-1256633534==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

Below is a draft of the meeting minutes.  I'm awaiting Warwick's 
document status inputs, but otherwise the minutes are complete and 
ready for comments, prior to submission to the IETF Secretariat.

As for slides, I have sets from Polk, Turner, Malpani, and Santesson. 
Stil missing are slides from:

P. Sylvester-EdelWeb
M. Myers-VeriSign
S. Farrell-SSE
D. Pinkas-Bull

Steve
-----

PKIX WG Meeting 3/29-00
Edited by Steve Kent (WG co-chair)

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

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX COMPLETED DOCUMENTS

<GET INPUT FROM WARWICK>

PKIX WORK IN PROGRESS

<GET INPUT FROM WARWICK>

ACTIVE PROJECTS:

Revisions to RFC 2459 & ECDSA (T. Polk-NIST)
New document published on 3/10/00, to fix errors, align with latest 
X.509 revisions, etc.  Major changes to certificate path validation 
are included, especially a detailed CRL processing section. ASN.1 
appendix was updated too. Authors still need to include some better 
examples. Suggestion made to remove the 1997 ASN.1 syntax, vs. the 
1988 syntax, to avoid inconsistencies. There was prior agreement to 
move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to 
remove section 7 and combine it with the ECDSA document to create a 
new PKIX document, devoted to algorithms. The authors plan to submit 
both documents for WG last call by the end of April. (See slides for 
more details.)

Qualified Certificates  (S. Santesson-AddTrust)
This ID has completed WG last call. A major debate arose with regard 
to use of the SerialNumber attribute as a means of differentiating 
between otherwise identical DNs, vs. using it as a unique ID 
irrespective of the rest of the DN. This is an example of a larger 
issue, i.e., situations where a subset of the DN is sufficient to 
uniquely identify a subject.  There is no general syntactic mechanism 
to specify what subset of a DN might exhibit this property, although 
one might convey this information via certificate policy or other 
means. Denis Pinkas responded with slides suggesting the need for a 
mechanism to solve a subtly different problem, i.e., defining a 
permanent identifier for a subject, even when the directory name 
changes, e.g., due to marriage, divorce, change of address, 
intra-organizational change, etc. Proposal is to create new name 
type, a new OID under OtherName, which is expressly used for this 
purpose, as an alternate subject name. This name form will be 
composed of DN attributes. No constraints would be imposed on the 
name form.  The uniqueness of the new name form is not global, but 
local to the issuer. Denis would like to add this to the QC document, 
but it was observed that the advertised benefits for permanent IDs 
apply outside of the QC context, e.g., for intra-organizational 
access control. A proposal was made to progress this as a separate, 
small document, which can be merged into the QC document or into 2459 
in the future, if there is suitable support.  The motivation here is 
to not derail the progress of the QC document. (See slides for more 
details.)

PKIX Roadmap  (S. Turner-IECA)
This document has been updated to version 5, which includes revisions 
to the POP and Key Usage sections. The author plans to include the 
recent debate on qualified certificates (see above). The suggestion 
is made to issue this document as an Informational RFC once the QC 
and revised part 1 documents are approved for publication as RFCs. 
The Informational RFC will be updated periodically to track the 
evolution of PKIX documents. (See slides for more details.)

Time Stamping Protocol  (D. Pinkas-Bull)
In addition to minor fixes and syntax changes to simplify the ASN.1, 
some changes were made to accommodate requests from an ISO committee 
that is also working on time stamping and wanted both protocols to be 
closely aligned. The changes made in TSP accommodated most but not 
all of the requests. A news version of the document will be issued 
soon, while we await a response from ISO re the current set of 
changes. (See slides for more details.)

DVCS  (P. Sylvester-EdelWeb)
This is the current version of the document that began as a notary 
protocol from Adams & Zuccherato, and then became the data 
certification service protocols, before editorial responsibility 
shifted. Motivation for this protocol is to support a central 
infrastructure for document security management, e.g., in an intranet 
or extranet environment, or for other long term secure document 
management. The protocol is designed to enable delegation of 
signature verification, notarization, and even certificate use 
controls to a server (vs. and end system). The presentation included 
a number of scenarios motivating the need for the protocol and its 
features. The question arises whether the complex document management 
system features described here is really an infrastructure component 
within the purview of this WG or it is more of an application? (See 
slides for more details.)

OCSP Extensions  (M. Myers-VeriSign)
The document has been significantly reduced in size, consistent with 
a reduced scope definition.  The newly defined scope includes: 
delegated path validation, validation path discovery, trusted point 
specification, and extended status replies. There was some discussion 
about possible ambiguity with regard to path validation, i.e., it is 
important that the server produce the same validation result as a 
local, RFC 2459-compliant implementation. A brief list of additional 
requirements was presented. A WG member noted that OCSP requires 
inclusion of the hash of parts of the issuer's certificate, which 
says that OCSPX cannot perform complete path validation for a client. 
Another WG member requested that the list be polled to determine if 
delegated path validation is a required facility to be provided by a 
PKIX work product. (See slides for more details.)

SCVP  (A. Malpani-ValiCert)
This presentation began with a review of OCSP and its rationale. 
Specifically, OCSP assumes that the client has constructed a 
validation chain and is just asking the server to check the status of 
each certificate in the chain. The motivation for SCVP is to offload 
path construction and validation to a server, as a response to 
customer requests, e.g., for limited processing environments or 
anywhere the client does not want to implement the complex task of 
path generation and validation. Unlike OCSPX, there is no presumption 
that the client has other than the target certificate available as a 
starting point for path validation. Here too one must verify that 
remote validation is a needed service. (See slides for more details.)

A small group will generate a requirements document to characterize 
the motivations for remote validation services, to define the 
requirements for such services, and to compare the candidate 
protocols relative to these requirements.  The group members will 
include the authors of the competing protocols and a WG co-chair.

Attribute Certificates (S. Farrell-SSE)
Small changes have been made to this document to maintain synch with 
the latest X.509 documents, plus minor fixes. Plan is to issue a new 
draft and move quickly to WG last call.

OTHER TOPICS

PKI Disclosure Statements (S. Santesson & M. Baum-VeriSign)
A section of the ABA ISC has proposed a new form of document to be 
issued by a CA.  The PKI Disclosure Statement (PDS) is not a 
replacement for a CP or CPS. Rather the PDS is intended to address 
certain consumer disclosure legal requirements for which a CP or CPS 
is inappropriate. The set of data to be included is small and well 
defined.  It might be represented in XML, although this is not an 
explicit requirement.

Mobile Credentials (S. Farrell-Baltimore)
Desire to provide a standard protocol for downloading/uploading 
credentials, e.g., for systems that have limited local storage.  This 
issue has been raised in the WAP forum, but it might be well pursued 
in the IETF, maybe in PKIX.

--============_-1256633534==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,

Below is a draft of the meeting minutes.  I'm awaiting Warwick's
document status inputs, but otherwise the minutes are complete and
ready for comments, prior to submission to the IETF Secretariat.

As for slides, I have sets from Polk, Turner, Malpani, and Santesson. 
Stil missing are slides from:

<bigger>P. Sylvester-EdelWeb

M. Myers-VeriSign

S. Farrell-SSE

D. Pinkas-Bull

Steve

-----

<fontfamily><param>Courier_New</param>PKIX WG Meeting 3/29-00 

Edited by Steve Kent (WG co-chair)

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

The meeting began with a review of the status of all of the WG
document, 

presented by Warwick Ford, WG co-chair. The following text summarizes
the 

status of the documents:

PKIX COMPLETED DOCUMENTS

<<GET INPUT FROM WARWICK>

PKIX WORK IN PROGRESS

<<GET INPUT FROM WARWICK>

ACTIVE PROJECTS:

Revisions to RFC 2459 & ECDSA (T. Polk-NIST)

New document published on 3/10/00, to fix errors, align with latest
X.509 revisions, etc.  Major changes to certificate path validation are
included, especially a detailed CRL processing section. ASN.1 appendix
was updated too. Authors still need to include some better examples.
Suggestion made to remove the 1997 ASN.1 syntax, vs. the 1988 syntax,
to avoid inconsistencies. There was prior agreement to move the ECDSA
algorithm into Part 1, but this is probably a bad idea due to the
changing algorithm landscape. Instead, the proposal is to remove
section 7 and combine it with the ECDSA document to create a new PKIX
document, devoted to algorithms. The authors plan to submit both
documents for WG last call by the end of April. (See slides for more
details.)

Qualified Certificates  (S. Santesson-AddTrust)

This ID has completed WG last call. A major debate arose with regard to
use of the SerialNumber attribute as a means of differentiating between
otherwise identical DNs, vs. using it as a unique ID irrespective of
the rest of the DN. This is an example of a larger issue, i.e.,
situations where a subset of the DN is sufficient to uniquely identify
a subject.  There is no general syntactic mechanism to specify what
subset of a DN might exhibit this property, although one might convey
this information via certificate policy or other means. Denis Pinkas
responded with slides suggesting the need for a mechanism to solve a
subtly different problem, i.e., defining a permanent identifier for a
subject, even when the directory name changes, e.g., due to marriage,
divorce, change of address, intra-organizational change, etc. Proposal
is to create new name type, a new OID under OtherName, which is
expressly used for this purpose, as an alternate subject name. This
name form will be composed of DN attributes. No constraints would be
imposed on the name form.  The uniqueness of the new name form is not
global, but local to the issuer. Denis would like to add this to the QC
document, but it was observed that the advertised benefits for
permanent IDs apply outside of the QC context, e.g., for
intra-organizational access control. A proposal was made to progress
this as a separate, small document, which can be merged into the QC
document or into 2459 in the future, if there is suitable support.  The
motivation here is to not derail the progress of the QC document. (See
slides for more details.)

PKIX Roadmap  (S. Turner-IECA)

This document has been updated to version 5, which includes revisions
to the POP and Key Usage sections. The author plans to include the
recent debate on qualified certificates (see above). The suggestion is
made to issue this document as an Informational RFC once the QC and
revised part 1 documents are approved for publication as RFCs.  The
Informational RFC will be updated periodically to track the evolution
of PKIX documents. (See slides for more details.)

Time Stamping Protocol  (D. Pinkas-Bull)

In addition to minor fixes and syntax changes to simplify the ASN.1,
some changes were made to accommodate requests from an ISO committee
that is also working on time stamping and wanted both protocols to be
closely aligned. The changes made in TSP accommodated most but not all
of the requests. A news version of the document will be issued soon,
while we await a response from ISO re the current set of changes. (See
slides for more details.)

DVCS  (P. Sylvester-EdelWeb)

This is the current version of the document that began as a notary
protocol from Adams & Zuccherato, and then became the data
certification service protocols, before editorial responsibility
shifted. Motivation for this protocol is to support a central
infrastructure for document security management, e.g., in an intranet
or extranet environment, or for other long term secure document
management. The protocol is designed to enable delegation of signature
verification, notarization, and even certificate use controls to a
server (vs. and end system). The presentation included a number of
scenarios motivating the need for the protocol and its features. The
question arises whether the complex document management system features
described here is really an infrastructure component within the purview
of this WG or it is more of an application? (See slides for more
details.)

OCSP Extensions  (M. Myers-VeriSign)

The document has been significantly reduced in size, consistent with a
reduced scope definition.  The newly defined scope includes: delegated
path validation, validation path discovery, trusted point
specification, and extended status replies. There was some discussion
about possible ambiguity with regard to path validation, i.e., it is
important that the server produce the same validation result as a
local, RFC 2459-compliant implementation. A brief list of additional
requirements was presented. A WG member noted that OCSP requires
inclusion of the hash of parts of the issuer's certificate, which says
that OCSPX cannot perform complete path validation for a client.
Another WG member requested that the list be polled to determine if
delegated path validation is a required facility to be provided by a
PKIX work product. (See slides for more details.)

SCVP  (A. Malpani-ValiCert)

This presentation began with a review of OCSP and its rationale. 
Specifically, OCSP assumes that the client has constructed a validation
chain and is just asking the server to check the status of each
certificate in the chain. The motivation for SCVP is to offload path
construction and validation to a server, as a response to customer
requests, e.g., for limited processing environments or anywhere the
client does not want to implement the complex task of path generation
and validation. Unlike OCSPX, there is no presumption that the client
has other than the target certificate available as a starting point for
path validation. Here too one must verify that remote validation is a
needed service. (See slides for more details.)

A small group will generate a requirements document to characterize the
motivations for remote validation services, to define the requirements
for such services, and to compare the candidate protocols relative to
these requirements.  The group members will include the authors of the
competing protocols and a WG co-chair. 

Attribute Certificates (S. Farrell-SSE)

Small changes have been made to this document to maintain synch with
the latest X.509 documents, plus minor fixes. Plan is to issue a new
draft and move quickly to WG last call.

OTHER TOPICS

PKI Disclosure Statements (S. Santesson & M. Baum-VeriSign)

A section of the ABA ISC has proposed a new form of document to be
issued by a CA.  The PKI Disclosure Statement (PDS) is not a
replacement for a CP or CPS. Rather the PDS is intended to address
certain consumer disclosure legal requirements for which a CP or CPS is
inappropriate. The set of data to be included is small and well
defined.  It might be represented in XML, although this is not an
explicit requirement.

Mobile Credentials (S. Farrell-Baltimore)

Desire to provide a standard protocol for downloading/uploading
credentials, e.g., for systems that have limited local storage.  This
issue has been raised in the WAP forum, but it might be well pursued in
the IETF, maybe in PKIX.
</fontfamily></bigger>

--============_-1256633534==_ma============--

Date: Tue, 11 Apr 2000 16:31:20 -0400
To: [email-masked]
From: TISC Program Committee <[email-masked]>
Subject: A Complimentary Afternoon of Events

A Complimentary Afternoon of Events for Internet Professionals

The Internet Security Conference (TISC) is fast approaching.
This year's conference will be held April 24-28 in San Jose
at the Fairmont Hotel.  During full-day and half-day workshops
and a two-day symposium, TISC will address some of the most
pressing security matters facing the Internet today:
Healthcare & Security, VPNs, PKI, Single Sign-on, IPsec,
Biometrics, Intrusion Detection, Network Forensics, Evidence
Gathering, Windows 2000 security, and more.

To register to attend TISC, call (800) 798-2928 or visit
https://secure.mactivity.com/tisc/registration.html

On Wednesday, April 26, TISC will offer a complementary
afternoon of events for all Internet professionals:

12:45 - 1:00	Presentation of the TISC CLUE AWARD
		to Marcus Ranum, CTO, Network Flight Recorder
		(http://tisc.corecom.com/faculty.html#ranum)

1:00 - 1:30	Keynote Address: Cultural Issues in Internet Security
		Marcus Ranum, CTO, Network Flight Recorder

1:30 - 3:00	Internet Security Product Showcase
		Complimentary refreshments and intimate demonstrations
		by over 40 public and private companies who are leading
		the way in Internet security

3:10 - 4:30	CTO Roundtable: Securing the Network Infrastructure
		CTOs discuss "hardening up" the network infrastructure to
		make it more survivable in real networking environments.
		  Moderator:	Steve Wadlow, Jerboa, Inc.
		  Panelists:	Nicko van Someren, CTO, nCipher
				Chini Krishnan, CTO, Valicert
				Clifford Neuman, CTO, CyberSafe
				Chris Klaus, CTO, ISS
				Charles Williams, CTO, Cylink

Learn more and register to attend this free afternoon of events
by visiting http://tisc.corecom.com 

Date: Tue, 11 Apr 2000 16:01:23 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Permanent identifiers in QC
Cc: [email-masked]

Tom,

>      I do not understand why permanent identifiers would be much less
>useful in a non-repudiation situation than in an access control situation.
>A third-party verifier is just as interested in distinguishing between two
>individuals named "John Smith" to decide whether the subject of the
>certificate used to sign a document in the past is the same person as the
>relying party claims it is as an access control system would be in whether
>the certificate subject is the owner of account "jsmith".  It is true that
>transaction volumes for NR verification would probably be low enough that
>manual techniques like checking what identification was presented to the CA
>or RA could be used in the absence of a permanent identifier, and that the
>verifier might wind up having to check the CA's records anyway, especially
>if certification masquerade is claimed.  However, access control systems
>may not think that a permanent ID match from a cross-certified CA is
>absolute proof of identity either, and might prefer storing specific
>certificate ID's.

I understand your point that under some circumstances it may be 
desirable to be able to determine if two different certs, involved in 
signing two different objects, are the same individual.  But that 
certainly is an extension of the basic non-repudiation service, which 
focuses on whether a given signature for a signed object is valid, 
relative to a set of rules re certificate issuance, path validation, 
revocation, etc.  We probably ought not add features to QC certs to 
address increasingly more complex scenarios, vs. the general case NR 
scenarios that the QC document editor has established as the scope of 
that effort.  For example, Denis's proposal does not ensure that one 
can compare the IDs in the new name form when they are issued under 
two different CAs. I can imagine applications where that might be an 
important feature, but that does not mean that we ought to define a 
construct for supporting such a facility.

In another example, the PKIX WG was treated to an impressive 
presentation in Adelaide on a protocol suite that supports very 
complex document management applications. It probably subsumes the 
functions of SCVP, OCSP, and maybe parts of CMP!  However, that 
protocol is probably too elaborate and too focused on a specific 
application context to match the WG charter of standardizing generic, 
infrastructure services and data formats.

Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: "Anders Rundgren" <[email-masked]>, "David P. Kemp" <[email-masked]>, [email-masked]
Date: Tue, 11 Apr 2000 14:12:47 -0400
Subject: Re: Permanent identifiers in QC

     I do not understand why permanent identifiers would be much less
useful in a non-repudiation situation than in an access control situation.
A third-party verifier is just as interested in distinguishing between two
individuals named "John Smith" to decide whether the subject of the
certificate used to sign a document in the past is the same person as the
relying party claims it is as an access control system would be in whether
the certificate subject is the owner of account "jsmith".  It is true that
transaction volumes for NR verification would probably be low enough that
manual techniques like checking what identification was presented to the CA
or RA could be used in the absence of a permanent identifier, and that the
verifier might wind up having to check the CA's records anyway, especially
if certification masquerade is claimed.  However, access control systems
may not think that a permanent ID match from a cross-certified CA is
absolute proof of identity either, and might prefer storing specific
certificate ID's.

          Tom Gindin

Stephen Kent <[email-masked]> on 04/10/2000 07:06:29 PM

To:   "Anders Rundgren" <[email-masked]>
cc:   "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject:  Re: Permanent identifiers in QC

Anders & Dave,

The scenario Dave provided is an access control example.  It is
broader than what Denis suggested in his presentation, and thus is
not what I was referring to, but it is still valid.

The emphasis on signatures verified using QC certificates has been on
their use in non-repudiable transactions.  In such cases, access
control may or may not be an issue.

Steve

Date: Tue, 11 Apr 2000 08:39:58 -0400
To: Oscar Jacobsson <[email-masked]>, Christopher Williams <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: Getting CA capabilities
Cc: PKIX Mailing List <[email-masked]>

At 01:44 PM 4/11/2000 +0200, Oscar Jacobsson wrote:
>Christopher Williams wrote:
> > There does not seem to be any way for an EE to obtain details of certain CA
> > capabilities, e.g. whether the CA supports key generation, whether the CA
> > supports key archival and retrieval, etc. unless the EE has intimate
> > knowledge of the CA.  Should the EE's client software be able to obtain
> > programmatically details about the server software's capabilities?  Is this
> > a possible GeneralInfo type?
>
>Would this not be best handled via the Authority Information Access
>extension? RFC 2459 sure does make it sound like a prime candidate for
>distributing such information:
>
>"The authority information access extension indicates how to access CA
>information and services for the issuer of the certificate in which
>the extension appears. Information and services may include on-line
>validation services and CA policy data."

But that is after the fact.  In CMP, you do not get the CA's cert until you 
get your Initialization Response.

As I pointed out to Chris in private, CMP has an out-of-band I&A process 
for IR's shared secret.  During this process, all CA policy can be handed 
to the EE.

Interestingly, if you were to want to use a QC cert to sign a CP in place 
of the out-of-band I&A and IR, then you DO need a programatic way for the 
EE to get the policy.

To this extent, I do not believe we KNOW all the items and values that 
would be expressed in a policy.  Or at least I have not seen any such 
document.  So for an EE programmer to deal with this, we first need to 
define what IS configurable policy, or at least those policy items that 
impact EE behaviour.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Tue, 11 Apr 2000 13:44:52 +0200
From: Oscar Jacobsson <[email-masked]>
Organization: Celo Communications AB
To: Christopher Williams <[email-masked]>
CC: PKIX Mailing List <[email-masked]>
Subject: Re: Getting CA capabilities

Christopher Williams wrote:
> There does not seem to be any way for an EE to obtain details of certain CA
> capabilities, e.g. whether the CA supports key generation, whether the CA
> supports key archival and retrieval, etc. unless the EE has intimate
> knowledge of the CA.  Should the EE's client software be able to obtain
> programmatically details about the server software's capabilities?  Is this
> a possible GeneralInfo type?

Would this not be best handled via the Authority Information Access
extension? RFC 2459 sure does make it sound like a prime candidate for
distributing such information:

"The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which
the extension appears. Information and services may include on-line
validation services and CA policy data."

//oscar

Date: Mon, 10 Apr 2000 19:06:29 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Permanent identifiers in QC
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>

Anders & Dave,

The scenario Dave provided is an access control example.  It is 
broader than what Denis suggested in his presentation, and thus is 
not what I was referring to, but it is still valid.

The emphasis on signatures verified using QC certificates has been on 
their use in non-repudiable transactions.  In such cases, access 
control may or may not be an issue.

Steve

Date: Mon, 10 Apr 2000 15:05:20 -0400
From: "Snow Katrina" <[email-masked]>
Organization: BAH
To: Carlisle Adams <[email-masked]>
CC: "'Christopher Williams'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Can anybody generate a PKI message?

unsubscribe

Carlisle Adams wrote:
> 
> Hi Chris,
> 
> Recall that IETF does not do interoperability testing within its official
> working groups.  Therefore, your message is somewhat inappropriate for the
> PKIX mailing list.  Rather, it should be sent to the ca-talk mailing list
> ([email-masked]), which was created explicitly for the purpose of
> facilitating interoperability testing for RFC 2510/2511.
> 
> Have you gotten in touch with Bob yet regarding joining the ca-talk list and
> future CMP interop bake-offs?
> 
> Carlisle.
> 
> > ----------
> > From:         Christopher Williams[SMTP:[email-masked]]
> > Sent:         Friday, April 07, 2000 10:54 AM
> > To:   PKIX Mailing List
> > Subject:      Can anybody generate a PKI message?
> >
> > Given an initial authentication key of, say, "b45t4r0-zx9?" and a
> > reference
> > value of, say, 0x269421C0, can anybody generate an initialization request
> > message containing a request for a signing key certificate with POP of a
> > signing key and protected by a password-based MAC, preferably using SHA-1
> > as
> > the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do
> > so
> > and mail it to me, I would be seriously grateful as I would like to be
> > able
> > to debug my implementations of PBM and POP against a real-world example.
> >
> > Thanks in advance,
> >
> > Chris Williams.
> >

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Permanent identifiers in QC
Date: Mon, 10 Apr 2000 21:04:05 +0100

David,

>Perhaps Steve meant access control in a broader sense than you mean it.

Could be.

>When a human views an authenticated identity, it might be solely for
>the purpose of being able to say "yeah, that's nice".  And a machine
>might capture an authenticated identity solely for tracking or audit
>purposes.

That is indeed a possible scenario but I does not appear to be main-stream.

>But for the applications you mention, there is a decision made on the
>basis of the authenticated identity: the bank grants access to a
>particular account, the authority grants access to a particular
>citizen's records.  Do you have in mind any scenario where an identity
>is authenticated but not used to mediate access to a resource?

Not really, in most cases a digital signature is supposed to initiate something
which in the end has to do with access to resources so access control in a wider
perspective in in my opionion not a marginal application, but THE application.
At least seen from a commercial point of view.

Anders

>Dave
>
>
>
>> From: "Anders Rundgren" <[email-masked]>
>> To: <[email-masked]>, "Stephen Kent" <[email-masked]>
>> Subject: Re: Permanent identifiers in QC
>> Date: Sun, 9 Apr 2000 17:32:07 +0100
>> 
>> >Looking over this thread, and recalling Denis's presentation in Adelaide, I 
>agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, 
>the motivations cited by Denis for his proposal are access control based and 
>thus NOT suitable for inclusion >in the QC document. Also, since there is still 
>disagreement over other motivations for such identifiers, and their form in QCs, 
>I think >it unwise to incluide them in the QC document at this late date. Thus I 
>believe that we are ready to proceed with the QC document.
>> 
>> Steve, you are right that it may be best to proceed with the QC document, but 
>you are definitely wrong when you
>> say that permanent IDs only apply to access control.  They apply to ANY 
>situation where the identity of the signer,
>> authenticator etc has to be verified on-line.  From Internet-banking to 
>authority-to-citizen communication.  At least if
>> TTPs are used as CAs for client certficates.
>> 
>> <snip>
>> 
>> Anders
>> 
>> 
>> 
>> 
>> 
>*******************************************************************************
>> This confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>> 
>*******************************************************************************

Date: Mon, 10 Apr 2000 13:15:21 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Permanent identifiers in QC
To: [email-masked]
Content-MD5: z+bdVsvEqWocXiL+KvwBLA==

Anders,

Perhaps Steve meant access control in a broader sense than you mean it.

When a human views an authenticated identity, it might be solely for
the purpose of being able to say "yeah, that's nice".  And a machine
might capture an authenticated identity solely for tracking or audit
purposes.

But for the applications you mention, there is a decision made on the
basis of the authenticated identity: the bank grants access to a
particular account, the authority grants access to a particular
citizen's records.  Do you have in mind any scenario where an identity
is authenticated but not used to mediate access to a resource?

Dave

> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>, "Stephen Kent" <[email-masked]>
> Subject: Re: Permanent identifiers in QC
> Date: Sun, 9 Apr 2000 17:32:07 +0100
> 
> >Looking over this thread, and recalling Denis's presentation in Adelaide, I 
agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, 
the motivations cited by Denis for his proposal are access control based and 
thus NOT suitable for inclusion >in the QC document. Also, since there is still 
disagreement over other motivations for such identifiers, and their form in QCs, 
I think >it unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.
> 
> Steve, you are right that it may be best to proceed with the QC document, but 
you are definitely wrong when you
> say that permanent IDs only apply to access control.  They apply to ANY 
situation where the identity of the signer,
> authenticator etc has to be verified on-line.  From Internet-banking to 
authority-to-citizen communication.  At least if
> TTPs are used as CAs for client certficates.
> 
> <snip>
> 
> Anders
> 
> 
> 
> 
> 
*******************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
*******************************************************************************

Date: Mon, 10 Apr 2000 12:13:37 -0400
To: "Christopher Williams" <[email-masked]>, "PKIX Mailing List" <[email-masked]>
From: Ari Kermaier <[email-masked]>
Subject: Re: Questionable fields in PKIX structures

Christopher, the following is my understanding of the spec for the fields 
you mentioned.

   -- Ari Kermaier

>PKIMessage.extraCerts

In a PKIMessage whose MessageBody content is a CertRepMessage certification 
response, if the CA is not a root CA, it may include additional 
certificates along with the EE's certificate that complete the verification 
chain.

>PKIHeader.freeText

A CA server might send a message in the freeText field for a human-operated 
client (e.g., a web browser) to display to the person, for example "Your 
certificates will be sent to you by email within the next 30 minutes".

>CertReqMsg.regInfo

Might contain information from the EE client to the CA server needed to 
issue the certificate e.g., the email address to which the certificate 
should be mailed, the client's credit card number, etc.

>RevDetails.crlEntryDetails

RFC 2459 Section 5.3 CRL Entry Extensions talks about this field. For 
example, it might contain a reason code explaining the revocation, the date 
the certificate became invalid, etc.

>CertResponse.rspInfo

Similar to CertReqMsg.regInfo, the rspInfo field may be used by the CA 
server to convey additional issuance info to the EE client needed for 
receiving/installing the certificate.

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Questionable fields in PKIX structures
Date: Mon, 10 Apr 2000 10:46:59 +0100

There are a number of structures in the PKIX specification which have fields
whose purpose in most unclear.  In many cases, I can write routines (indeed
have written routines) to access them, but I can't fathom what they'd be
used for.  If anybody can give an explanation of the purpose of the
following fields (and possibly an example of how they might be used in a
real world scenario) I would be very grateful:

PKIMessage.extraCerts
PKIHeader.freeText
CertReqMsg.regInfo
RevDetails.crlEntryDetails
CertResponse.rspInfo

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Getting CA capabilities
Date: Mon, 10 Apr 2000 10:34:04 +0100

There does not seem to be any way for an EE to obtain details of certain CA
capabilities, e.g. whether the CA supports key generation, whether the CA
supports key archival and retrieval, etc. unless the EE has intimate
knowledge of the CA.  Should the EE's client software be able to obtain
programmatically details about the server software's capabilities?  Is this
a possible GeneralInfo type?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: Permanent identifiers in QC
Date: Sun, 9 Apr 2000 17:32:07 +0100

<snip>

>Looking over this thread, and recalling Denis's presentation in Adelaide, I agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, the motivations cited by Denis for his proposal are access control based and thus NOT suitable for inclusion >in the QC document. Also, since there is still disagreement over other motivations for such identifiers, and their form in QCs, I think >it unwise to incluide them in the QC document at this late date. Thus I believe that we are ready to proceed with the QC document.

Steve, you are right that it may be best to proceed with the QC document, but you are definitely wrong when you
say that permanent IDs only apply to access control.  They apply to ANY situation where the identity of the signer,
authenticator etc has to be verified on-line.  From Internet-banking to authority-to-citizen communication.  At least if
TTPs are used as CAs for client certficates.

<snip>

Anders

From: "PortalProfesional.com" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sat, 08 Apr 2000 17:40:08 -0300
Subject: LEAME, ES IMPORTANTE - www.portalprofesional.com
Reply-To: [email-masked]

Muchas Preguntas:
- Estas Buscando Empleo?
- Tienes empleo pero quieres uno mejor?
- No sabes donde dejar tu Curriculum?
- Eres Profesional o a punto de egresar?
- Ud es una Empresa y necesita hacer publicidad?
- Necesitas EMAIL Gratis?
- Necesitas Pagina Web Gratis?
- Ud es una Consultora o Empresa y necesita publicar sus Busquedas Laborales?
- Nunca encuentras lo que buscas en Internet?

UNA SOLA RESPUESTA: www.portalprofesional.com

VISITANOS. No te vas a arrepentir!
ICQ: 64451825
www.portalprofesional.com.ar

Date: Fri, 7 Apr 2000 17:16:48 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Permanent identifiers in QC

--============_-1256980272==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

I have worked my way through most of the 1600+ messages that arrived 
during the two weeks I was in vacation in NZ prior to the IETF 
meetings (when I chose not to read mail), plus a week in Australia 
w/o e-mail access (where I was, for various reasons, not able to read 
mail).

Looking over this thread, and recalling Denis's presentation in 
Adelaide, I agree with Stefan that IF we were to adopt a permanent ID 
name type in PKIX, the motivations cited by Denis for his proposal 
are access control based and thus NOT suitable for inclusion in the 
QC document.  Also, since there is still disagreement over other 
motivations for such identifiers, and their form in QCs, I think it 
unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.

Mike and Russ argue that the creation of new name forms based on a 
perceived semantic requirement is outside the scope of PKIX, i.e., it 
should be an application-specific profile created by the appropriate 
WG. I am sympathetic to these observations, but I also agree that if 
there is a need for such forms of IDs, and if they span multiple 
applications, then we could reasonably define them in PKIX.  It's 
clear that there is not general agreement on this point for now, and 
that leads me to say that we ought not put a new name form into the 
updated 2459 that is now in progress. However, i do not object to 
Denis writing a brief I-D describing the proposed new name form, and 
the motivations for it, and having that progress as a separate work 
item.  If it turns out that there is substantial support for this, 
both in the WG and in implementations, then we could merge it into 
2459 at a future date.

Comments?

Steve

--============_-1256980272==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,

I have worked my way through most of the 1600+ messages that arrived
during the two weeks I was in vacation in NZ prior to the IETF meetings
(when I <underline>chose not</underline> to read mail), plus a week in
Australia w/o e-mail access (where I was, for various reasons,
<underline>not able</underline> to read mail).

Looking over this thread, and recalling Denis's presentation in
Adelaide, I agree with Stefan that IF we were to adopt a permanent ID
name type in PKIX, the motivations cited by Denis for his proposal are
access control based and thus NOT suitable for inclusion in the QC
document.  Also, since there is still disagreement over other
motivations for such identifiers, and their form in QCs, I think it
unwise to incluide them in the QC document at this late date. Thus I
believe that we are ready to proceed with the QC document.

Mike and Russ argue that the creation of new name forms based on a
perceived semantic requirement is outside the scope of PKIX, i.e., it
should be an application-specific profile created by the appropriate
WG. I am sympathetic to these observations, but I also agree that if
there is a need for such forms of IDs, and if they span multiple
applications, then we could reasonably define them in PKIX.  It's clear
that there is not general agreement on this point for now, and that
leads me to say that we ought not put a new name form into the updated
2459 that is now in progress. However, i do not object to Denis writing
a brief I-D describing the proposed new name form, and the motivations
for it, and having that progress as a separate work item.  If it turns
out that there is substantial support for this, both in the WG and in
implementations, then we could merge it into 2459 at a future date.

Comments?

Steve

--============_-1256980272==_ma============--

Date: Fri, 07 Apr 2000 13:33:50 -0400
To: "PKIX Mailing List" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: CMP Interop Testing

This is a call to anyone who is actively developing CMP (RFC 2510 & 2511, 
well now ID 2510bis):

Now that the dust has settled a bit around 2510bis, it is time to restart 
Interop testing.

The testing will be virtual, and the mailing list that will be supporting 
the testing work is [email-masked].  We hope to start the testing the 
first week of May.  If you wish to participate in the testing, please send 
an email to me at [email-masked].

Testing will be in small units over a series of sessions, allowing code 
corrections and new players.  Times will be slotted to allow for global 
testing (though it is not expected that any time will work for all time 
zones, a group of times will hopefully cover).

The first session will focus on IR/RR over TCP (a new TCP/HTTP draft will 
be out early next week, I was promised).  Details for the testing are 
starting now.

The goal is to have made significant progress by Pittsburg and to be 
finished by San Diego.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Fri, 07 Apr 2000 13:20:03 -0400
To: "Christopher Williams" <[email-masked]>, "PKIX Mailing List" <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: OIDs of MACing algorithms

At 10:43 AM 4/4/2000 +0100, Christopher Williams wrote:
>Does anybody know the algorithm identifiers for MACing algorithms such as
>DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
>based MAC?

Buried in Senario B2 it says for IR the manditory is HMAC-SHA1:

PasswordBasedMac:
   {1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
     parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;

A few others have missed this piece of information.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Fri, 07 Apr 2000 13:00:22 -0400
To: [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: RFC 2511 (CRMF) OID question

In RFC 2511 Section 7, the following definition is presented for using
name-value pairs as a registration control:
-----------------------------------
    id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
    --with syntax OCTET STRING
-----------------------------------

In Appendix C, the following definition is given, which appears to
introduce an OID conflict:
-----------------------------------
id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
-----------------------------------

And in Appendix B.1, the following definition appears to introduce an
ambiguity regarding the definition of the UTF8Pairs type
(UTF8String or OCTET STRING ?):
-----------------------------------
    When regInfo is used to convey one or more name-value pairs (via id-
    regInfo-utf8Pairs), the first and subsequent pairs SHALL be
    structured as follows:

       [name?value][%name?value]*%

    This string is then encoded into an OCTET STRING and placed into the
    regInfo SEQUENCE.
-----------------------------------

Can anyone clarify this for me?

Ari Kermaier <[email-masked]>

From: Carlisle Adams <[email-masked]>
To: "'Christopher Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Can anybody generate a PKI message?
Date: Fri, 7 Apr 2000 11:36:23 -0400 

Hi Chris,

Recall that IETF does not do interoperability testing within its official
working groups.  Therefore, your message is somewhat inappropriate for the
PKIX mailing list.  Rather, it should be sent to the ca-talk mailing list
([email-masked]), which was created explicitly for the purpose of
facilitating interoperability testing for RFC 2510/2511.

Have you gotten in touch with Bob yet regarding joining the ca-talk list and
future CMP interop bake-offs?

Carlisle.

> ----------
> From: 	Christopher Williams[SMTP:[email-masked]]
> Sent: 	Friday, April 07, 2000 10:54 AM
> To: 	PKIX Mailing List
> Subject: 	Can anybody generate a PKI message?
> 
> Given an initial authentication key of, say, "b45t4r0-zx9?" and a
> reference
> value of, say, 0x269421C0, can anybody generate an initialization request
> message containing a request for a signing key certificate with POP of a
> signing key and protected by a password-based MAC, preferably using SHA-1
> as
> the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do
> so
> and mail it to me, I would be seriously grateful as I would like to be
> able
> to debug my implementations of PBM and POP against a real-world example.
> 
> Thanks in advance,
> 
> Chris Williams.
> 

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Can anybody generate a PKI message?
Date: Fri, 7 Apr 2000 15:54:28 +0100

Given an initial authentication key of, say, "b45t4r0-zx9?" and a reference
value of, say, 0x269421C0, can anybody generate an initialization request
message containing a request for a signing key certificate with POP of a
signing key and protected by a password-based MAC, preferably using SHA-1 as
the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do so
and mail it to me, I would be seriously grateful as I would like to be able
to debug my implementations of PBM and POP against a real-world example.

Thanks in advance,

Chris Williams.

From: Borselius N <[email-masked]>
To: "'Maxim Masiutin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Incorporaion of PGP Certificates into X.509v3 Certificates.
Date: Thu, 6 Apr 2000 23:24:41 +0100 

Maxim,

If I understand it correctly you are storing signed PGP keys within an X.509
extension. I suppose it makes sense for compatibility reasons but does look
a bit awkward at a first look, to store signed information along with the
signature itself (that's how PGP certs are constructed) within a X.509
field.

I am not fully clued up with PGP, (so please excuse my possibly silly
questions). I know PGP does encoding differently from other apps such as
S/MIME but does PGP use any of the same algorithms that are specified RFC
2459? And would it be possible to separate the information stored in a PGP
certificate (such as public key, owner identity, signature, algorithm ...)?

Cheers,
Niklas

-----Original Message-----
From: Maxim Masiutin [mailto:[email-masked]]
Sent: 03 April 2000 11:58
To: [email-masked]
Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.

Hello!

   I tried to submit "Incorporaion of PGP Certificates into X.509v3
   Certificates" draft, but it was IETF meeting. I post my draft here
   until IETF will be ready to accept new drafts. You comments are very
   welcome.

Internet Draft                                      M. Masiutin
                                                    RITLABS
April 3, 2000
expires in six months

   Incorporaion of PGP Certificates into X.509v3 Certificates.

   Copyright 2000 by The Internet Society. All Rights Reserved.

--- snip

From: Michael Myers <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked]
Subject: RE: Permanent identifiers in QC
Date: Thu, 6 Apr 2000 13:02:08 -0700 

All,

I agree with Russ.  I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  We establish
means by which entity identification values can be bound to a public key.
We do not establish requirements on specific instances.  That is the task of
other WGs.  

Mike

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, March 31, 2000 11:52 PM
> To: [email-masked]
> Subject: Re: Permanent identifiers in QC
> 
> 
> I cannot see any reason for PKIX to specify a permanent identifier.
> 
> In my view, it is the job of PKIX (in the son-of-RFC2459 
> document and the 
> companion QC document) to specify the means to bind an 
> identity to a public 
> key.  This does not include specifying new methods of specifying an 
> identity.  If some Internet application needs a permanent 
> identifier, then 
> the needy application should specify it.  Once it is 
> specified, it can be 
> used in certificates, just like all of the other name forms that are 
> already supported.
> 
> Russ
> 
> 
> At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
> >The PKIX meeting in Adelaide raised only 1 issue related to 
> the QC draft.
> >
> >This issue is whether we should include a new name form in the
> >subjectAltName extension holding  a permanent identifier.
> >
> >The permanent identifier would then be a name of the 
> subject, unique within
> >the issuers domain, that is not reused over time for another subject.
> >
> >The reason to include such a name form would be that the use 
> of serialNumber
> >in DN, or directoryName in subjectAltName extension, does 
> not explicitly
> >define this property by itself, unless seen in the light of 
> a defined policy
> >etc.
> >
> >Chair Stephen Kent decided that the decision whether or not 
> to include this
> >name form in QC should be taken to the list.
> >
> >My observation in regards to this is:
> >
> >1) Adding this name form would add confusion to the QC 
> specification since
> >it would overlap use of serialNumber in the DN.
> >
> >2) Use of DN attributes covers all needs related to 
> identification of the
> >subject, and that's all we need to support electronic 
> signatures, at least
> >as seen from the EU-directive. And as far I know, this goes 
> for any other
> >legal system.
> >
> >3) Use of DN in combination with either implicit knowledge, 
> use of Directory
> >name in the subjectAltname ext, use of a related policy 
> identifier or use of
> >information in the qcStatements extension also provide 
> support for use of
> >permanent identifiers identified as such.
> >
> >4) In each and every case raised in favor of this new name 
> form, the benefit
> >relates to access control rather than electronic signatures.
> >
> >5) This is a new input to the discussion, which before 
> adoption must be
> >reviewed by the community over some time.
> >
> >Observation 4 makes this whole discussion outside the scope 
> of QC and in
> >combination with the other observations, I would request 
> that the QC is
> >moved forward to proposed standard without this new name form.
> >
> >If PKIX at a later stage would find that a permanent 
> identifier solution, as
> >discussed here, is of general value, then this can be moved 
> forward as a
> >separate item. At that time we would also know if it should 
> be merged with
> >RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> >/Stefan
> 

From: Carlisle Adams <[email-masked]>
To: "'Christopher Williams'" <[email-masked]>
Cc: PKIX Mailing List <[email-masked]>
Subject: RE: Certificate confirmation
Date: Thu, 6 Apr 2000 09:59:20 -0400 

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[email-masked]]
> Sent: 	Thursday, April 06, 2000 9:35 AM
> To: 	PKIX Mailing List
> Subject: 	Certificate confirmation
> 
> In the first version of RFC 2510, POP of an encryption key could be
> established by decrypting a certificate sent by a CA and using the
> symmetric
> key used to encrypt it as the input to a password-based MAC used to
> protect
> a subsequent PKIConfirm message.
> 
> The second version adds the certificate confirmation message which
> incorporates a hash of the certificate.  This will effectively prove POP
> of
> an encryption key if the certificate was encrypted.  Does the protocol
> still
> expect the confirmation message to be protected by a password-based MAC
> which has the symmetric key used to encrypt the certificate as its input?
 
No, this is no longer expected, but it is certainly permissible.  The MAC
based on this key is no longer needed to do POP, but the message still
requires some form of integrity.  So, you can do a MAC based on this key, or
a MAC based on some other shared password, or a signature, or whatever (as
long as it is clear to the receiver what you're doing and which key you're
using).

Carlisle.

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Certificate confirmation
Date: Thu, 6 Apr 2000 14:35:00 +0100

In the first version of RFC 2510, POP of an encryption key could be
established by decrypting a certificate sent by a CA and using the symmetric
key used to encrypt it as the input to a password-based MAC used to protect
a subsequent PKIConfirm message.

The second version adds the certificate confirmation message which
incorporates a hash of the certificate.  This will effectively prove POP of
an encryption key if the certificate was encrypted.  Does the protocol still
expect the confirmation message to be protected by a password-based MAC
which has the symmetric key used to encrypt the certificate as its input?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com

Reply-To: <[email-masked]>
From: "±Ç¿ëÃ¶" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OIDs of MACing algorithms
Date: Thu, 6 Apr 2000 21:22:31 +0900
Importance: Normal

>  hello,
> Check out for OID's in  this site...
> 
>  www.alvestrand.no/objectid

	sorry. I have already known the site. 

	but it doesn't have. :-(

To: [email-masked]
Date: Thu, 06 Apr 2000 02:42:15 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: RE: OIDs of MACing algorithms
Organization: MailCity  (http://www.mailcity.lycos.com:80)

 hello,

Check out for OID's in  this site...

 www.alvestrand.no/objectid

chandar
--

On Thu, 6 Apr 2000 09:06:33    1G?kC6 wrote:
>> PKCS#5 might be what you're looking for. Check out 
>> www.rsasecurity.com/rsalabs 
>> - Tolga
>> >>> "Christopher Williams" <[email-masked]> 4/4/00 
>> 3:43:38 >>>
>> Does anybody know the algorithm identifiers for MACing 
>> algorithms such as
>> DES-MAC, Triple-DES-MAC, etc. that might be used as the basis 
>> of a password based MAC?
>
>	Thanks christopher! That's what I want to ask! :-)
>	Tolga, I read the PKCS#5 but it doesn't help me.
>
>	It specify PBE, but we just want to know the OID of DES-MAC and
>	Triple-DES-MAC in FIPS-113. 
>
>	I guess if the OID exsists, it may be under 1.3.14.3.2.(it's algorithms)
>	and 1.3.14.3.2.10 is desMAC we can use it but PKCS#11 specifies
>	3-DES-MAC doesn't require parameter and there is no way to specify
>	the key length if we use desMAC oid(that's why I looking for the OID of
>	3-DES-MAC :-( ).
>
>	I hope that the new PKCS#11 release contains the OIDs but I couldn't
>	download it from RSA ftp - it was shutdowned in these 2 days :-(.
>
>	Does any body knows it?
>
>	Thanks!
>

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

Reply-To: <[email-masked]>
From: "±Ç¿ëÃ¶" <[email-masked]>
To: "'Tolga Acar'" <[email-masked]>, <[email-masked]>
Subject: RE: OIDs of MACing algorithms
Date: Thu, 6 Apr 2000 09:06:33 +0900
Importance: Normal

> PKCS#5 might be what you're looking for. Check out 
> www.rsasecurity.com/rsalabs 
> - Tolga
> >>> "Christopher Williams" <[email-masked]> 4/4/00 
> 3:43:38 >>>
> Does anybody know the algorithm identifiers for MACing 
> algorithms such as
> DES-MAC, Triple-DES-MAC, etc. that might be used as the basis 
> of a password based MAC?

	Thanks christopher! That's what I want to ask! :-)
	Tolga, I read the PKCS#5 but it doesn't help me.

	It specify PBE, but we just want to know the OID of DES-MAC and
	Triple-DES-MAC in FIPS-113. 

	I guess if the OID exsists, it may be under 1.3.14.3.2.(it's algorithms)
	and 1.3.14.3.2.10 is desMAC we can use it but PKCS#11 specifies
	3-DES-MAC doesn't require parameter and there is no way to specify
	the key length if we use desMAC oid(that's why I looking for the OID of
	3-DES-MAC :-( ).

	I hope that the new PKCS#11 release contains the OIDs but I couldn't
	download it from RSA ftp - it was shutdowned in these 2 days :-(.

	Does any body knows it?

	Thanks!

Date: Wed, 05 Apr 2000 19:21:30 -0400
To: :
From: Ari Kermaier <[email-masked]>
Subject: RFC 2511 (CRMF) OID question

In RFC 2511 Section 7, the following definition is presented for using
name-value pairs as a registration control:
-----------------------------------
    id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
    --with syntax OCTET STRING
-----------------------------------

In Appendix C, the following definition is given, which appears to
introduce an OID conflict:
-----------------------------------
id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
-----------------------------------

And in Appendix B.1, the following definition appears to introduce an
ambiguity regarding the definition of the UTF8Pairs type
(UTF8String or OCTET STRING ?):
-----------------------------------
    When regInfo is used to convey one or more name-value pairs (via id-
    regInfo-utf8Pairs), the first and subsequent pairs SHALL be
    structured as follows:

       [name?value][%name?value]*%

    This string is then encoded into an OCTET STRING and placed into the
    regInfo SEQUENCE.
-----------------------------------

Can anyone clarify this for me?

Ari Kermaier <[email-masked]>

To: [email-masked]
Subject: cRLDistributionPoints errors
From: Peter Gutmann <[email-masked]>
Sender: Peter Gutmann <[email-masked]>
Date: Wed,  5 Apr 2000 17:59:09 -0400 (EDT)

Currently there are two mutually incompatible interpretations of
cRLDistributionPoints floating around.  The reason for this is that the use of
GeneralNames is causing confusion among implementors, with the result that
we're seeing certs with either of the following two formatting options:

  SEQUENCE {
    OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
    OCTET STRING, encapsulates {
        SEQUENCE {
          SEQUENCE {
            [0] {
              [0] {
                [2] 'wibble'
                }
              }
            }
          }
        }
    }

  SEQUENCE {
    OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
    OCTET STRING, encapsulates {
        SEQUENCE {
          SEQUENCE {
            [0] {
              [0] {
                SEQUENCE {
                  [2] 'wibble'
                  }
                }
              }
            }
          }
        }
    }

(I've deleted the CA's URL's :-).  Note the extra SEQUENCE in the second one,
which IMHO is wrong:

   fullName [0] GeneralNames
-> fullName [0] IMPLICIT SEQUENCE OF GeneralName
-> fullName [0] GeneralName

(ie the SEQUENCE gets eaten by the parent tag).  Here's what happens when you
feed these to some common software:

                 IE4             IE5         Netscape
Implicit tag     OK              OK             OK
Explicit tag     OK              X              OK

I suspect that NS4 and IE4 are ignoring the extension, which is why they don't
complain about the explicit tagging, while IE5, which doesn't ignore it, is
rejecting it.

It looks like we're stuck with both forms for the forseeable future (does
anyone know which software is generating the broken form?  I get sent these
things by my spies, but since they're often from obscure CA's I can't figure
out what the originating application is).  If it'd possible to get some idea of
how widespread this is it's possible to determine whether you can say "It's
busted, go away" or whether you have to add yet another nondeterministic
parsing kludge to your ASN.1 parser to handle it.

Peter.

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
Date: Wed, 5 Apr 2000 15:39:44 +0200
Importance: Normal

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.36ECA9D6--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I just try to study the path validation and stumbled over the section that
has been discussed in a thread with this subject a month ago.

The section currently reads:

  (e) If the subjectPublicKeyInfo field of the certificate contains
      an algorithm field with non-null parameters, assign the parameters
      to the working_public_key_parameters variable.

      If the subjectPublicKeyInfo field of the certificate contains an
      algorithm field with null parameters or parameters are omitted,
      compare the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm.  If the certificate subjectPublicKey
      algorithm and the working_public_key_algorithm are different, set
      the working_public_key_parameters to null.

for me this is mildly confusing, and <<probably>> contradictory to what I
understood was the outcome of the thread. My understanding of that outcome
could be

  (e)	If the certificate subjectPublicKey algorithm and the
	working_public_key_algorithm are different, set the
	working_public_key_parameters to null.

	Otherwise (if the certificate subjectPublicKey algorithm
	and the working_public_key_algorithm are the same), if the
	subjectPublicKeyInfo field of the certificate contains an
	algorithm field where parameters have not been omitted,
	assign these parameters to the working_public_key_parameters
	variable.

If I misunderstood things - I beg for enlightenment

Peter

----IAIK.SMIME.MAPPER.36ECA9D6--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAAA
----IAIK.SMIME.MAPPER.36ECA9D6----

Date: Tue, 04 Apr 2000 16:06:05 -0400
To: "Ozols, Maris" <[email-masked]>, [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Cert Path Validation in pkix-new-part1

--=====================_7864357==_.ALT
Content-Type: text/plain; charset="us-ascii"

Maris,

I understand your concern with the possibility that a CA could use policy mapping to issue certificates under policies that it was not "authorized" to use. However, I do not believe that the problem is a great as you suggest.

Using your example, the policy tree created by the path processing algorithm would look something like this (although the P-HIGH at Level 1 would be deleted):

Level 0:        any-policy
                 /       \
                /         \
Level 1:   P-HIGH        P-LOW
                            |
                            |
Level 2:                 P-LOW
                         /     \
                        /       \
Level 3:            P-LOW     P-HIGH

As you suggest, in this scenario an end-entity could be issued a certificate under the policy P-HIGH. However, I believe that a relying party accepting such a certificate path would treat the path as if it had been accepted under the policy specified at Level 1 (P-LOW in this case). The reason for this is that the policies at Level 1 are the policies of the relying party's domain and thus, presumably, the policies that the relying party understands. In general, the relying party should not expect to be familiar with the policies that appear further down in the tree, as these policies may have been introduced as a result of policy mapping. So, while CA2 may succeed in issuing certificates under a policy that CA1 did not authorize it to use, this does not result in CA2's end-entities being granted any additional privileges.

It should also be noted that the main reason for the change in the algorithm was to properly address issues of transitive trust. For example, suppose that Company A makes widgets and buys parts from Company B. In order to enable secure communication/purchasing/design sharing/etc., Company A and Company B cross-certify their CAs. Since Companies A and B are trading partners, each company trusts the other to properly issue certificates under its own policies. By cross-certifying, the relying parties at Company B can validate the certificates of employees at Company A. However, Company A also has a trading partner relationship with Company B's competitor, Company C. So Company A and Company B are cross-certified.

While Company A trusts Company C to issue certificates properly, Company B does not. In fact, Company B wants to ensure that its employees (acting as relying parties) will not validate any certificates issued by Company C no matter what the certificates that Company C issues look like.

In this scenario, Company B will issue a cross-certificate to Company A under policy P-A with policy mapping P-A --> P-B and with policy mapping inhibited. Similarly, Company A will issue a cross-certificate to Company C under policy P-B, with policy mapping P-B --> P-C. Using the new path processing algorithm, Company B's relying parties will reject all certificates issued by Company C. Using the old path processing algorithm, on the other hand, it would have been possible for Company C to get its certificates accepted by Company B's relying parties by issuing certificates under either policy P-B or P-A.

At 03:26 PM 4/4/00 +0930, Ozols, Maris wrote:
>Hi,
>
>I have a question about pkix-new-part1.
>
>My understanding is that a major reason for the new-part1 was to deal with
>certificates that validated under RFC2459, when they really ought not to
>have. It seems that policy mappings can still be used to introduce cert
>policies in validated certificates which might have been thought excluded.  
>
>Consider the following scenario. CA1 holds (is subject of) a cert with cert
>policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child CA
>within the same security domain) with a cert that only includes {P-LOW}. CA1
>does not want CA2 to issue valid certificates with {P-HIGH} (perhaps because
>they are linked to access control over which CA2 has no authority).
>
>Then, provided that policy mappings are still permitted at this level, CA2
>could issue a self-certificate (maybe when doing a rekey) with the policy
>mapping {(P-LOW --> P-HIGH), (P-LOW --> P-LOW)}. Then CA2 may issue
>certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2 could
>certifiy another CA3 (which is also not permitted to issue P-HIGH certs)
>with the same mapping, and thus enabling CA3 to issue certs with P-HIGH. 
>
>Is inhibitPolicyMapping the only way of avoiding such abuse (given the new
>algorithm)? Note that this might not always be a viable option, as you may
>wish to allow legitimate policy mappings from CA2. Consider the case where
>CA2 is primarily involved with the external relations/e-commerce of your
>organisation, and thus may need to have extensive flexibility to
>cross-certify into commercial and business-partner PKI's. However CA2 is
>considered too exposed to be permitted to issue P-HIGH certificates (which
>are only intended for internal use). 
>
>It might be a preferable to consider an algorithm such that when issuers
>explicitly omit cert policies down the chain (as CA1 did for P-HIGH to CA2)
>that these be tracked in the algorithm as an excluded set which can't be
>mapped into. Is this an option worth pursuing? Alternatively, maybe there
>should be some words to explain that the cert policies extension in a CAs
>certificate provides little control over a CA, if it is still permitted
>policy mapping. More generally, it would be nice to have some guidance on
>how cert policies and other associated extensions can achieve a given
>outcome. I think that at the moment the 2459 (and new-part1) explanations of
>the intended semantics of cert policies for end-entity certs is simple and
>well-defined, but this is not the case for cert policies in CA certificates.
>
>Maris

--=====================_7864357==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Maris,<br>
<br>
I understand your concern with the possibility that a CA could use policy
mapping to issue certificates under policies that it was not
&quot;authorized&quot; to use. However, I do not believe that the problem
is a great as you suggest.<br>
<br>
Using your example, the policy tree created by the path processing
algorithm would look something like this (although the P-HIGH at Level 1
would be deleted):<br>
<br>
<tt>Level 0:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; any-policy<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
Level 1:&nbsp;&nbsp; P-HIGH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
Level
2:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
Level
3:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW&nbsp;&nbsp;&nbsp;&nbsp; P-HIGH<br>
<br>
</tt>As you suggest, in this scenario an end-entity could be issued a
certificate under the policy P-HIGH. However, I believe that a relying
party accepting such a certificate path would treat the path as if it had
been accepted under the policy specified at Level 1 (P-LOW in this case).
The reason for this is that the policies at Level 1 are the policies of
the relying party's domain and thus, presumably, the policies that the
relying party understands. In general, the relying party should not
expect to be familiar with the policies that appear further down in the
tree, as these policies may have been introduced as a result of policy
mapping. So, while CA2 may succeed in issuing certificates under a policy
that CA1 did not authorize it to use, this does not result in CA2's
end-entities being granted any additional privileges.<br>
<br>
It should also be noted that the main reason for the change in the
algorithm was to properly address issues of transitive trust. For
example, suppose that Company A makes widgets and buys parts from Company
B. In order to enable secure communication/purchasing/design
sharing/etc., Company A and Company B cross-certify their CAs. Since
Companies A and B are trading partners, each company trusts the other to
properly issue certificates under its own policies. By cross-certifying,
the relying parties at Company B can validate the certificates of
employees at Company A. However, Company A also has a trading partner
relationship with Company B's competitor, Company C. So Company A and
Company B are cross-certified.<br>
<br>
While Company A trusts Company C to issue certificates properly, Company
B does not. In fact, Company B wants to ensure that its employees (acting
as relying parties) will not validate any certificates issued by Company
C no matter what the certificates that Company C issues look like.<br>
<br>
In this scenario, Company B will issue a cross-certificate to Company A
under policy P-A with policy mapping P-A --&gt; P-B and with policy
mapping inhibited. Similarly, Company A will issue a cross-certificate to
Company C under policy P-B, with policy mapping P-B --&gt; P-C. Using the
new path processing algorithm, Company B's relying parties will reject
all certificates issued by Company C. Using the old path processing
algorithm, on the other hand, it would have been possible for Company C
to get its certificates accepted by Company B's relying parties by
issuing certificates under either policy P-B or P-A.<br>
<br>
<br>
At 03:26 PM 4/4/00 +0930, Ozols, Maris wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I have a question about pkix-new-part1.<br>
<br>
My understanding is that a major reason for the new-part1 was to deal
with<br>
certificates that validated under RFC2459, when they really ought not
to<br>
have. It seems that policy mappings can still be used to introduce
cert<br>
policies in validated certificates which might have been thought
excluded.&nbsp; <br>
<br>
Consider the following scenario. CA1 holds (is subject of) a cert with
cert<br>
policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child
CA<br>
within the same security domain) with a cert that only includes {P-LOW}.
CA1<br>
does not want CA2 to issue valid certificates with {P-HIGH} (perhaps
because<br>
they are linked to access control over which CA2 has no authority).<br>
<br>
Then, provided that policy mappings are still permitted at this level,
CA2<br>
could issue a self-certificate (maybe when doing a rekey) with the
policy<br>
mapping {(P-LOW --&gt; P-HIGH), (P-LOW --&gt; P-LOW)}. Then CA2 may
issue<br>
certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2
could<br>
certifiy another CA3 (which is also not permitted to issue P-HIGH
certs)<br>
with the same mapping, and thus enabling CA3 to issue certs with P-HIGH.
<br>
<br>
Is inhibitPolicyMapping the only way of avoiding such abuse (given the
new<br>
algorithm)? Note that this might not always be a viable option, as you
may<br>
wish to allow legitimate policy mappings from CA2. Consider the case
where<br>
CA2 is primarily involved with the external relations/e-commerce of
your<br>
organisation, and thus may need to have extensive flexibility to<br>
cross-certify into commercial and business-partner PKI's. However CA2
is<br>
considered too exposed to be permitted to issue P-HIGH certificates
(which<br>
are only intended for internal use). <br>
<br>
It might be a preferable to consider an algorithm such that when
issuers<br>
explicitly omit cert policies down the chain (as CA1 did for P-HIGH to
CA2)<br>
that these be tracked in the algorithm as an excluded set which can't
be<br>
mapped into. Is this an option worth pursuing? Alternatively, maybe
there<br>
should be some words to explain that the cert policies extension in a
CAs<br>
certificate provides little control over a CA, if it is still
permitted<br>
policy mapping. More generally, it would be nice to have some guidance
on<br>
how cert policies and other associated extensions can achieve a
given<br>
outcome. I think that at the moment the 2459 (and new-part1) explanations
of<br>
the intended semantics of cert policies for end-entity certs is simple
and<br>
well-defined, but this is not the case for cert policies in CA
certificates.<br>
<br>
Maris<br>
</blockquote><br>
</html>

--=====================_7864357==_.ALT--

Date: Tue, 04 Apr 2000 08:56:24 -0600
From: "Tolga Acar" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: OIDs of MACing algorithms

PKCS#5 might be what you're looking for. Check out www.rsasecurity.com/rsalabs 

- Tolga

>>> "Christopher Williams" <[email-masked]> 4/4/00 3:43:38 >>>
Does anybody know the algorithm identifiers for MACing algorithms such as
DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
based MAC?

Cheers

From: "Darren Harter" <[email-masked]>
To: <[email-masked]>
Cc: "'Hans Schupp'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Tue, 4 Apr 2000 14:49:53 +0100
Importance: Normal

John,

Thanks for this.  I'm sure they'll be a few on the list, thinking "I didn't
know OCTET STRINGs could do that!"  Segmenting of OCTET STRINGs is certainly
a feature I wasn't aware of - it's good to know that even after 10 years of
ASN.1 the language can still turn around and bite me on the butt.

Kind regards,

Darren

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 04 April 2000 14:22
To: Darren Harter
Cc: 'Hans Schupp'; [email-masked]; [email-masked]
Subject: RE: ASN.1 , Constructed Encoding

Daren Hunter wrote:

>Given this, the IA5String that we are discussing is slightly
>strange as the three encodings that contain the 'test1', '@',
>and 'rsa.com' parts collectively form the 'DATA' part of the
>encoding for a single IA5String - I think we're probably in
>agreement up to this point.  These parts should fall under
>the specific rules for encoding the value of IA5Strings.  If the
>IA5String rules state that the component parts should be encoded
>as OCTET STRINGs, then you are right and 04 tags should be used
>for the component parts.  However, if the rules for IA5String
>say that the component parts should be encoded as IA5Strings
>(using the above definition), then IMHO you are wrong, and 16
> tags should be used.

X680 (or rather ISO/IEC 8825-1) says:

"Each character string type shall be encoded as if it had been declared
[UNIVERSAL x] IMPLICIT OCTET STRING"

This means that encoding a character string is a two-part process:

1) take the sequence of octets that makes up the character
string value and encode it as an OCTET STRING.

3) replace the tag of the OCTET STRING encoding with the tag for
"UNIVERSAL x".

The section that defines character string encoding doesn't mention
segmenting the string into substrings using constructed encoding -
that option comes from the OCTET STRING encoding in step 1, so it
must follow the rules for segmenting OCTET STRINGS, which says
explicitly when referring to segmented encodings that "In particular,
the tags in the contents octets are always universal class, number 4".

One interesting "feature" of this is that, since the segmentation
happens at the OCTET STRING level, the segment breaks may occur in the
middle of a character code if the codeset is a multi-byte one.

John

From: [email-masked]
Subject: RE: ASN.1 , Constructed Encoding
To: "Darren Harter" <[email-masked]>
Cc: "'Hans Schupp'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 4 Apr 2000 09:21:46 -0400

Daren Hunter wrote:

>Given this, the IA5String that we are discussing is slightly
>strange as the three encodings that contain the 'test1', '@',
>and 'rsa.com' parts collectively form the 'DATA' part of the
>encoding for a single IA5String - I think we're probably in
>agreement up to this point.  These parts should fall under
>the specific rules for encoding the value of IA5Strings.  If the
>IA5String rules state that the component parts should be encoded
>as OCTET STRINGs, then you are right and 04 tags should be used
>for the component parts.  However, if the rules for IA5String
>say that the component parts should be encoded as IA5Strings
>(using the above definition), then IMHO you are wrong, and 16
> tags should be used.

X680 (or rather ISO/IEC 8825-1) says:

"Each character string type shall be encoded as if it had been declared
[UNIVERSAL x] IMPLICIT OCTET STRING"

This means that encoding a character string is a two-part process:

1) take the sequence of octets that makes up the character
string value and encode it as an OCTET STRING.

3) replace the tag of the OCTET STRING encoding with the tag for
"UNIVERSAL x".

The section that defines character string encoding doesn't mention
segmenting the string into substrings using constructed encoding -
that option comes from the OCTET STRING encoding in step 1, so it
must follow the rules for segmenting OCTET STRINGS, which says
explicitly when referring to segmented encodings that "In particular,
the tags in the contents octets are always universal class, number 4".

One interesting "feature" of this is that, since the segmentation
happens at the OCTET STRING level, the segment breaks may occur in the
middle of a character code if the codeset is a multi-byte one.

John

From: "Darren Harter" <[email-masked]>
To: "'Hans Schupp'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Tue, 4 Apr 2000 11:13:27 +0100
Importance: Normal

Hans,

No need to appologise, your English is perfectly clear.  I think we are
probably both correct but about different things, and our discussion may
have been at slightly cross perposes.  Let me try and explain.
Unfortunately, I don't have a copy of X.690 to hand here, but my
understanding is that for all standard ASN.1 types there can be three and
only three forms of encoding.  Let's take BOOLEAN as an example, go back to
first principles and gain some common ground:

Type1:	BOOLEAN

This encodes as 01 01 'DATA' where DATA is 0 for false, and non-zero for
true (always FF in DER).  Where the leading 01 is the boolean tag
([UNIVERSAL 1]) and the second 01 is the length.

Type2:	<Tag> IMPLICIT BOOLEAN

Let's consider the case where tag is [0] - i.e [0] IMPLICIT BOOLEAN.  When
the IMPLICIT keyword is present, the normal tag is replaced by the indicated
tag and the encoding in this case becomes 80 01 'DATA' where the 'DATA' and
01 have exactly the same meaning as in Type 1.

Type3:	<Tag> EXPLICIT BOOLEAN

Let's again consider the case where tag is [0] - i.e. [0] EXPLICIT BOOLEAN.
When the EXPLICIT keyword is present, the normal tag is retained in the
encoding and the indicated tag is prepended.  The encoding therefore becomes
A0 03 01 01 'DATA'.  Essentially, the original encoding from Type 1 becomes
the 'Value' part of an outer encoding.  In this case the outer tag is 'A0'
not '80' as its 'DATA' contains an ASN.1 encoding (01 01 FF) and therefore
has to be flagged as constructed.  EXPLICITly encoded types are always
flagged as constructed.

As far as I am aware, these are the rules for the 'encoding of a tagged
value'.

Following the above rules for a Type 2 definition of IA5String of [UNIVERSAL
22] IMPLICIT OCTET STRING, the normal tag for OCTET STRING (04) would not
appear in the encoding of an IA5String, but the 'DATA' part of the encoding
will be formed according to the rules for OCTET STRINGs - i.e. I arbitrary
stream of 8-bit words.

Given this, the IA5String that we are discussing is slightly strange as the
three encodings that contain the 'test1', '@', and 'rsa.com' parts
collectively form the 'DATA' part of the encoding for a single IA5String - I
think we're probably in agreement up to this point.  These parts should fall
under the specific rules for encoding the value of IA5Strings.  If the
IA5String rules state that the component parts should be encoded as OCTET
STRINGs, then you are right and 04 tags should be used for the component
parts.  However, if the rules for IA5String say that the component parts
should be encoded as IA5Strings (using the above definition), then IMHO you
are wrong, and 16 tags should be used.

In your version of the encoding we have a ASN.1 equal to:

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF OCTET STRING

whereas in my version we have

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF IA5String
IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING

With IMPLICIT exchanged for EXPLICIT in my other example.

What is important for this discussion is what the 'DATA' encoding rules for
IA5String say.

Can anybody post an appropriate paragraph from X.680/X.690 that describes
the internal 'DATA' encoding of IA5String?

Kind regards,

Darren

-----Original Message-----
From: Hans Schupp [mailto:[email-masked]]
Sent: 03 April 2000 17:35
To: Darren Harter
Cc: [email-masked]; [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

Darren Harter wrote:

> The IMPLICIT keywords forces the encoding of OCTET STRING, but not
> its tag.  So in the case of IA5String, it is indeed 0x36 when
> constructed (or part of an explicit encoding) and 0x16 when not
> constructed (and not part of an explicit encoding).

Agree. But this is no contradiction to my posting.

> If the definition was
>   IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
> instead of
>   IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
> you would get the following:
>
> 36 1B 04 19
>                 36 07 04 05 test1
>                 36 03 04 01 @
>                 36 09 04 07 rsa.com

No, definitely not.
Please read carefully X.690 paragraph 8.14 ("Encoding of a tagged
value"). You will find, that the encoding of a tagged value is done by
taking the encoding of the base type (OCTET STRING in our discussion)
and adding the explicit tag in front of it.

So the example string encoded as
  [UNIVERSAL 16] EXPLICIT OCTET STRING
becomes
  36 15 04 13
              04 05 test1
              04 01 @
              04 07 rsa.com

The respective is valid for implicit tagging: the base encoding is
modified by throwing away the original tag and using the new one instead
(while preseving the "constructed" bit).
Please have a look at paragraph 8.14.3 for exact wording.

> Because it is IMPLICIT the three contained strings fall back to
> their default (unconstructed) tags on 0x16, but the outer
> (constructed) tag stays a 0x36.  The explicit OCTET STRING tags
> of 0x04 disappear in this case.
>
> The original poster's encoding was correct as
>
> 36 13
>         16 05 test1
>         16 01 @
>         16 07 rsa.com

No. I still stay with my original argument.

The example we use here has great resemblance with the example used in
paragraph 8.20.6 of X.690. That one supports my point of view.

> You are correct in that the only leagal X.690 encoding of this is
> in a single non-constructed IA5String with the following encoding:
>
> 16 0D [email-masked]

I'm sorry, if my English isn't good enough to make myself clear.
I didn't mean to say _that_, but the following:
Even though the encoding is done in three chunks (which is perfectly
valid in BER, but not in DER), the logical string that is expressed by
this encoding is the same as "[email-masked]" encoded in one chunk.

Best regards,
Hans Schupp

PS: I refer to X.690 (1994 E) aka ISO/IEC 8825-1: 1995 (E)

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: OIDs of MACing algorithms
Date: Tue, 4 Apr 2000 10:43:38 +0100

Does anybody know the algorithm identifiers for MACing algorithms such as
DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
based MAC?

Cheers

Sender: [email-masked]
Date: Tue, 04 Apr 2000 12:19:03 +0200
From: Markus Heintel <[email-masked]>
Organization: Siemens AG
To: [email-masked]
Subject: unsubscribe

unsubscribe

From: "Christopher Williams" <[email-masked]>
To: "PKIX Mailing List" <[email-masked]>
Subject: Purpose of caPubs field
Date: Tue, 4 Apr 2000 09:43:59 +0100

Can anybody tell me what is the prupose of the caPubs field in the PKIX
CertRepMessage structure?

Thanks.

From: "Ozols, Maris" <[email-masked]>
To: [email-masked]
Subject:  Cert Path Validation in pkix-new-part1
Date: Tue, 4 Apr 2000 15:26:35 +0930 

Hi,

I have a question about pkix-new-part1.

My understanding is that a major reason for the new-part1 was to deal with
certificates that validated under RFC2459, when they really ought not to
have. It seems that policy mappings can still be used to introduce cert
policies in validated certificates which might have been thought excluded.  

Consider the following scenario. CA1 holds (is subject of) a cert with cert
policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child CA
within the same security domain) with a cert that only includes {P-LOW}. CA1
does not want CA2 to issue valid certificates with {P-HIGH} (perhaps because
they are linked to access control over which CA2 has no authority).

Then, provided that policy mappings are still permitted at this level, CA2
could issue a self-certificate (maybe when doing a rekey) with the policy
mapping {(P-LOW --> P-HIGH), (P-LOW --> P-LOW)}. Then CA2 may issue
certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2 could
certifiy another CA3 (which is also not permitted to issue P-HIGH certs)
with the same mapping, and thus enabling CA3 to issue certs with P-HIGH. 

Is inhibitPolicyMapping the only way of avoiding such abuse (given the new
algorithm)? Note that this might not always be a viable option, as you may
wish to allow legitimate policy mappings from CA2. Consider the case where
CA2 is primarily involved with the external relations/e-commerce of your
organisation, and thus may need to have extensive flexibility to
cross-certify into commercial and business-partner PKI's. However CA2 is
considered too exposed to be permitted to issue P-HIGH certificates (which
are only intended for internal use). 

It might be a preferable to consider an algorithm such that when issuers
explicitly omit cert policies down the chain (as CA1 did for P-HIGH to CA2)
that these be tracked in the algorithm as an excluded set which can't be
mapped into. Is this an option worth pursuing? Alternatively, maybe there
should be some words to explain that the cert policies extension in a CAs
certificate provides little control over a CA, if it is still permitted
policy mapping. More generally, it would be nice to have some guidance on
how cert policies and other associated extensions can achieve a given
outcome. I think that at the moment the 2459 (and new-part1) explanations of
the intended semantics of cert policies for end-entity certs is simple and
well-defined, but this is not the case for cert policies in CA certificates.

Maris

To: [email-masked]
Subject: ASN.1 Clarification for Son of RFC2459
Date: Tue, 04 Apr 2000 14:17:53 +1000
From: Dean Povey <[email-masked]>

Hi all,

The new Certificate and CRL profile contains an appendix giving some 
implementation guidance with respect to ASN.1.  I would also like to add a 
paragraph here explaining the encoding of BIT STRING, particularly as it 
relates to the KeyUsage extension which is sometimes encoded incorrectly 
according to DER rules (I've made this mistake myself).  

The DER rules for BIT STRING (in addition to the BER rules) from X.690 are:

1. Must use primitive encoding.

2. Unused bits in the final octet string must be zero

However there is a third rule which is often forgotten (in particular it 
is not mentioned in the layman's guide published by RSA labs).

3. Where X.680 21.7 Applies (I'll get to that in a moment), the bitstring 
shall have all trailing zero bits removed before it is encoded.

x.680 21.7 refers to the use of a NamedBitList, in other words where the 
definition also gives some symbolic names to bits.  Note this then applies 
to KeyUsage extension, which is:

KeyUsage ::= BIT STRING {
        digitalSignature     (0),
        nonRepudiation       (1),
        keyEncipherment      (2),
        dataEncipherment     (3),
        keyAgreement         (4),
        keyCertSign          (5),
        cRLSign              (6),
        encipherOnly         (7),
        decipherOnly         (8) }

So in the case of KeyUsage if you do not set decipherOnly the bit string 
should be encoded in a single octet.

NB: I _think_ the following examples are correct :-)

e.g: digitalSignature | nonRepudiation

03 02 06 C0

e.g: decipherOnly

03 03 07 00 80

The first example is sometimes wrongly encoded:

03 02 07 C0 00

Which is correct for BER, but not for DER.

Is there any thoughts about whether it is sensible to add a statement 
about this to Son of RFC2459?

Also another comment, The End-Entity certificate example in Son of RFC 
2459 D.3 has the some of the SEQUENCEs BER encoded, which I don't believe is correct.

Cheers.

-- 
Dean Povey,         | e-m: [email-masked]     | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120       |  security.dstc.edu.au/ 
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - C++ PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re:  Permanent identifiers in QC
Date: Mon, 3 Apr 2000 22:23:40 +0100

Tom,

>     But I don't think you answered my questions.  Why is "the serial
>number in the subject DN was assigned by the following naming authority"
>not a valid QC statement?  Also, why are "the serial number in the subject
>DN represents a national identity number" or "the serial number in the
>subject DN was assigned locally by the issuer" not valid QC statements?

I agree that these look like valid QC statements but I doubt that they
are universal enough.   If you need "the serial number + organization in the
subject DN is a permanent ID within the local CA domain" you run into
problems.   We do need some kind of extension but it should be parameterized
to cover different naming schemes.  IMO at least.

Anders
<snip>

From: [email-masked]
To: "Darren Harter" <[email-masked]>
cc: "'Hans Schupp'" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 3 Apr 2000 12:51:32 -0400
Subject: RE: ASN.1 , Constructed Encoding

     I thought, as you did, that the sensible encoding would have an inner
tag of 0x16 for IA5String.  Unfortunately for this viewpoint, X.690 section
8.20.5.4 gives a VisibleString example with an inner tag of 0x04 rather
than 0x1A.  For that matter, so does X.209 section 23.5.4.
     I'm sorry to have been wrong in the first place, but I hope this
clears up a misconception that I am sure was shared by more than just the
two of us.

          Tom Gindin

"Darren Harter" <[email-masked]> on 04/03/2000 11:51:49 AM

To:   "'Hans Schupp'" <[email-masked]>
cc:   <[email-masked]>, <[email-masked]>
Subject:  RE: ASN.1 , Constructed Encoding

Hans,

[UNIVERSAL X] IMPLICIT OCTET STRING always gets a tag encoded as (in
binary)
001X XXXX where XXXXX is the X in the [UNIVERSAL X].  The IMPLICIT keywords
forces the encoding of OCTET STRING, but not its tag.  So in the case of
IA5String, it is indeed 0x36 when constructed (or part of an explicit
encoding) and 0x16 when not constructed (and not part of an explicit
encoding).

If the definition was IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
instead of IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING you would get
the following:

36 1B 04 19
          36 07 04 05 test1
          36 03 04 01 @
          36 09 04 07 rsa.com

Because it is IMPLICIT the three contained strings fall back to their
default (unconstructed) tags on 0x16, but the outer (constructed) tag stays
a 0x36.  The explicit OCTET STRING tags of 0x04 disappear in this case.

The original poster's encoding was correct as

36 13
     16 05 test1
     16 01 @
     16 07 rsa.com

You are correct in that the only leagal X.690 encoding of this is in a
single non-constructed IA5String with the following encoding:

16 0D [email-masked]

Hope this all helps,

Darren

---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.

Tel: +44 (0) 1452 371383
Fax: +44 (0) 1452 371384
Cell:     +44 (0) 7801 812850

Mail: <mailto:[email-masked]>
Web: <http://www.entegrity.com>

---------------------------------------------------------------------
Visit us on Stand No 654 at Infosecurity 2000 and enter our
FREE competition to WIN A HALF CASE OF CHAMPAGNE!

11-13 April in the National Hall, Olympia Exhibition Centre, London
---------------------------------------------------------------------

-----Original Message-----
From: Hans Schupp [mailto:[email-masked]]
Sent: 03 April 2000 16:08
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

[email-masked] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)

> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp

Date: Mon, 03 Apr 2000 18:35:15 +0200
From: Hans Schupp <[email-masked]>
Organization: SECUDE GmbH
To: Darren Harter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------E14A830606770A8F8F917484
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Darren Harter wrote:

> The IMPLICIT keywords forces the encoding of OCTET STRING, but not
> its tag.  So in the case of IA5String, it is indeed 0x36 when
> constructed (or part of an explicit encoding) and 0x16 when not
> constructed (and not part of an explicit encoding).

Agree. But this is no contradiction to my posting.

> If the definition was 
>   IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
> instead of 
>   IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
> you would get the following:
> 
> 36 1B 04 19
>                 36 07 04 05 test1
>                 36 03 04 01 @
>                 36 09 04 07 rsa.com

No, definitely not.
Please read carefully X.690 paragraph 8.14 ("Encoding of a tagged
value"). You will find, that the encoding of a tagged value is done by
taking the encoding of the base type (OCTET STRING in our discussion)
and adding the explicit tag in front of it.

So the example string encoded as 
  [UNIVERSAL 16] EXPLICIT OCTET STRING
becomes
  36 15 04 13
              04 05 test1
              04 01 @
              04 07 rsa.com

The respective is valid for implicit tagging: the base encoding is
modified by throwing away the original tag and using the new one instead
(while preseving the "constructed" bit).
Please have a look at paragraph 8.14.3 for exact wording.

> Because it is IMPLICIT the three contained strings fall back to
> their default (unconstructed) tags on 0x16, but the outer
> (constructed) tag stays a 0x36.  The explicit OCTET STRING tags
> of 0x04 disappear in this case.
> 
> The original poster's encoding was correct as
> 
> 36 13
>         16 05 test1
>         16 01 @
>         16 07 rsa.com

No. I still stay with my original argument.

The example we use here has great resemblance with the example used in
paragraph 8.20.6 of X.690. That one supports my point of view.

> You are correct in that the only leagal X.690 encoding of this is
> in a single non-constructed IA5String with the following encoding:
> 
> 16 0D [email-masked]

I'm sorry, if my English isn't good enough to make myself clear.
I didn't mean to say _that_, but the following:
Even though the encoding is done in three chunks (which is perfectly
valid in BER, but not in DER), the logical string that is expressed by
this encoding is the same as "[email-masked]" encoded in one chunk.

Best regards,
Hans Schupp

PS: I refer to X.690 (1994 E) aka ISO/IEC 8825-1: 1995 (E)
--------------E14A830606770A8F8F917484
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Landwehrstr. 50a=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------E14A830606770A8F8F917484--

From: "Darren Harter" <[email-masked]>
To: "'Hans Schupp'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Mon, 3 Apr 2000 16:51:49 +0100
Importance: Normal

Hans,

[UNIVERSAL X] IMPLICIT OCTET STRING always gets a tag encoded as (in binary)
001X XXXX where XXXXX is the X in the [UNIVERSAL X].  The IMPLICIT keywords
forces the encoding of OCTET STRING, but not its tag.  So in the case of
IA5String, it is indeed 0x36 when constructed (or part of an explicit
encoding) and 0x16 when not constructed (and not part of an explicit
encoding).

If the definition was IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
instead of IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING you would get
the following:

36 1B 04 19
		36 07 04 05 test1
		36 03 04 01 @
		36 09 04 07 rsa.com

Because it is IMPLICIT the three contained strings fall back to their
default (unconstructed) tags on 0x16, but the outer (constructed) tag stays
a 0x36.  The explicit OCTET STRING tags of 0x04 disappear in this case.

The original poster's encoding was correct as

36 13
	16 05 test1
	16 01 @
	16 07 rsa.com

You are correct in that the only leagal X.690 encoding of this is in a
single non-constructed IA5String with the following encoding:

16 0D [email-masked]

Hope this all helps,

Darren

---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.

Tel:	+44 (0) 1452 371383
Fax:	+44 (0) 1452 371384
Cell:	+44 (0) 7801 812850

Mail: <mailto:[email-masked]>
Web: <http://www.entegrity.com>

---------------------------------------------------------------------
Visit us on Stand No 654 at Infosecurity 2000 and enter our
FREE competition to WIN A HALF CASE OF CHAMPAGNE!

11-13 April in the National Hall, Olympia Exhibition Centre, London
---------------------------------------------------------------------

-----Original Message-----
From: Hans Schupp [mailto:[email-masked]]
Sent: 03 April 2000 16:08
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

[email-masked] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)

> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp

From: [email-masked]
To: "Stefan Santesson" <[email-masked]>
cc: [email-masked]
Date: Mon, 3 Apr 2000 11:22:57 -0400
Subject: Re: SV: SV: Permanent identifiers in QC

     But I don't think you answered my questions.  Why is "the serial
number in the subject DN was assigned by the following naming authority"
not a valid QC statement?  Also, why are "the serial number in the subject
DN represents a national identity number" or "the serial number in the
subject DN was assigned locally by the issuer" not valid QC statements?
     These are certainly "defined statements related to Qualified
Certificates", and there is no other place for them in the certificate.  If
qcStatements are restricted purely to statements of policy, why is not the
extension redundant with the existing policy extension?  The present
solution does NOT provide for statements of this sort to go into the
certificate except insofar as an OTHER-NAME could be defined outside the
profile, and to say that it does so "as far as it ought to" is to say that
there should be no standard way of putting them in.  Note that Russ
Housley, at least, is opposed to putting any new name forms into either
profile.
     Your example of the qualifying information is, in fact, a case of
either "assigned by the following naming authority" or "represents a
national identity number".  If these features are to be made widely
interoperable, the object identifiers should be in one of the common
profiles.  I agree that we should move forward, but with this feature
rather than without it.

          Tom Gindin

"Stefan Santesson" <[email-masked]> on 04/03/2000 07:49:16 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[email-masked]>
Subject:  SV: SV: Permanent identifiers in QC

Tom,

I support your concerns.

I believe though that what the present solution already handles the issues
that you are addressing. At least as far as it ought to.

The qcStatemsnts extension are there to express policy statements. The
predefined statement is there to express that the certificate follows
syntax
and semantics of the QC profile. The optional qualifying information may
hold information that the certificate further adopts to a certain ID-scheme
(such as a specific Italian ID-scheme).

I don't think we should expand that feature beyond that.

What I think we should do know is to move this forward.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]]
> Skickat: den 1 april 2000 09:14
> Till: Stefan Santesson
> Kopia: [email-masked]
> Ämne: Re: SV: Permanent identifiers in QC
>
>
>      I take your point about duplicating the serial number using the
> two-name form I proposed for
> id-qcs-identifierAssignmentAuthority, and I
> hereby withdraw that suggestion.
>      However, assuming that adding name information in the
> qcStatements
> extension contradicts the purpose of that extension, I still
> do not see why
> the one-name version of id-qcs-identifierAssignmentAuthority,
> in which the
> only name in the extension is the name of the identifier assignment
> authority, contradicts the purpose of the extension.  The
> draft's current
> definition says about the name component: "The
> NameRegistrationAuthorities
> component, if present, SHALL contain a name of one or more name
> registration authorities, responsible for registration of
> attributes or
> names associated with the subject."  Why does the assigner of a serial
> number not fit into this definition of a registration authority?
>      Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
> semantics of an existing attribute in a DN within the
> certificate.  How
> does that contradict the statement that a semantics ID "may define
> semantics for all, or for a subgroup of all present attributes and/or
> names"?  Perhaps it would be more in keeping with the spirit
> of the profile
> if there were two different OID's for each of these three
> semantics, one to
> interpret subject name serial numbers and one to interpret subject
> alternate name serial numbers, but that is not a reason not
> to have the
> feature available.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[email-masked]> on 03/31/2000 06:45:54 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
>       <[email-masked]>
> cc:   <[email-masked]>
> Subject:  SV: Permanent identifiers in QC
>
>
>
> Tom,
>
> Using this extension to contain subject name information
> would break the
> intent of this extension.
>
> /Stefan
>
> > -----Ursprungligt meddelande-----
> > Från: [email-masked] [mailto:[email-masked]]
> > Skickat: den 31 mars 2000 09:10
> > Till: Stefan Santesson
> > Kopia: [email-masked]
> > Ämne: Re: Permanent identifiers in QC
> >
> >
> >      I have a counter-proposal.  Given the profile defined for
> > serialNumber, and the definition of SemanticsInformation in
> > draft section
> > 3.2.5.1, a semanticsIdentifier known as
> > id-qcs-identifierAssignmentAuthority should be assigned with
> > the following
> > rules of interpretation: either one or two name registration
> > authorities
> > must be present, and the first one present shall be
> interpreted as the
> > authority governing the name space, while the second
> > (optional) one may
> > contain the serial number or other unique identifier; if
> > there is only one
> > name registration authority present, the unique identifier is
> > assumed to be
> > the serial number attribute of the subject name if there is a
> > serial number
> > attribute in it, and the first serial number attribute
> > encountered in the
> > subject alternate name if there is none in the subject
> name.  Another
> > semanticsIdentifier known as id-qcs-CALocal should be
> > assigned to identify
> > serial numbers assigned locally within the CA.  Optionally, a
> > semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> > assigned with the rule that when one searches for the serial
> > number in the
> > subject name and subject alternate name in the same way as
> > for identifier
> > assignment authorities with only one name registration
> authority, the
> > serial number shall be interpreted as being assigned by the
> > country given
> > in the DN where the serial number is found.
> >
> >           Tom Gindin
> >
> >
> > "Stefan Santesson" <[email-masked]> on 03/30/2000 01:49:44 AM
> >
> > To:   <[email-masked]>
> > cc:
> > Subject:  Permanent identifiers in QC
> >
> >
> >
> > The PKIX meeting in Adelaide raised only 1 issue related to
> > the QC draft.
> >
> > This issue is whether we should include a new name form in the
> > subjectAltName extension holding  a permanent identifier.
> >
> > The permanent identifier would then be a name of the subject,
> > unique within
> > the issuers domain, that is not reused over time for
> another subject.
> >
> > The reason to include such a name form would be that the use of
> > serialNumber in DN, or directoryName in subjectAltName
> > extension, does not
> > explicitly define this property by itself, unless seen in the
> > light of a
> > defined policy etc.
> >
> > Chair Stephen Kent decided that the decision whether or not
> > to include this
> > name form in QC should be taken to the list.
> >
> > My observation in regards to this is:
> >
> > 1) Adding this name form would add confusion to the QC
> > specification since
> > it would overlap use of serialNumber in the DN.
> >
> > [Tom Gindin]   Why would this cause confusion if the name
> > form itself had
> > the same syntax as a DN, and the identity were in the serialNumber
> > attribute of that name?
> >
> > 2) Use of DN attributes covers all needs related to
> > identification of the
> > subject, and that's all we need to support electronic
> > signatures, at least
> > as seen from the EU-directive. And as far I know, this goes
> > for any other
> > legal system.
> >
> > [Tom Gindin]   This does not cover the joint specification of
> > an ID and an
> > assignment authority.  A single ID field with quasi-arbitrary values
> > similar to a serial number has meaning primarily within the
> > scope of its
> > assignment authority.
> >
> > 3) Use of DN in combination with either implicit knowledge, use of
> > Directory name in the subjectAltname ext, use of a related policy
> > identifier or use of information in the qcStatements
> > extension also provide
> > support for use of permanent identifiers identified as such.
> >
> > [Tom Gindin]   No rule for implicit knowledge which would permit an
> > arbitrary RP to recognize a permanent identifier and its assignment
> > authority within a DN (whether subject name or alt name)
> has yet been
> > received with favor.  However, it should be possible to do
> > this using the
> > semanticsIdentifier.
> >
> > 4) In each and every case raised in favor of this new name form, the
> > benefit relates to access control rather than electronic signatures.
> >
> > [Tom Gindin]   Allowing organizations to assign permanent
> > identifiers of
> > this type (most usually, but not necesarily, to employees)
> > has roughly the
> > same impact on signatures as on access control.  If it is
> > assumed that the
> > identity number is assigned by a governmental or quasi-governmental
> > authority, then the serial number is sufficient because my
> > above arguments
> > for assignment authority become irrelevant.
> >
> > 5) This is a new input to the discussion, which before
> > adoption must be
> > reviewed by the community over some time.
> >
> > [Tom Gindin]   It has been under discussion for months.
> >
> > Observation 4 makes this whole discussion outside the scope
> > of QC and in
> > combination with the other observations, I would request that
> > the QC is
> > moved forward to proposed standard without this new name form.
> >
> > [Tom Gindin]   If QC requires that the serial number be
> > assigned either by
> > a governmental or quasi-governmental authority as a permanent
> > identifier or
> > by the CA as a tiebreaker, and that the certificate itself contain
> > somewhere an indicator of whether the name is a permanent
> > identifier or a
> > tiebreaker, then this name form would not be relevant to
> > QC's.  Otherwise
> > it would.
> >
> > If PKIX at a later stage would find that a permanent
> > identifier solution,
> > as discussed here, is of general value, then this can be
> > moved forward as a
> > separate item. At that time we would also know if it should
> > be merged with
> > RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> > /Stefan
> >
>
>
>

Date: Mon, 03 Apr 2000 17:08:09 +0200
From: Hans Schupp <[email-masked]>
Organization: SECUDE GmbH
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: ASN.1 , Constructed Encoding

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------357AC187ABCE6F8B37C4A970
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)

> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp
--------------357AC187ABCE6F8B37C4A970
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Landwehrstr. 50a=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------357AC187ABCE6F8B37C4A970--

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Mon, 3 Apr 2000 10:51:59 -0400
Subject: Re: ASN.1 , Constructed Encoding

     The 0x20 bit of the tag byte (or the tag first byte when the tag value
is 31 or above) means "constructed".  Thus a constructed IA5 string will
have an outer tag of 0x36 and an inner tag of 0x16, a constructed octet
string will have an outer tag of 0x24 and an inner tag of 0x04, and a
constructed bit string with definition [2] IMPLICIT BIT STRING would have
an outer tag of 0xA2 and an inner tag of 0x03 while a primitive with that
definition would have a tag of 0x82.
     Maybe somebody else can answer you about word delimiters, since I'm
not sure what you mean.  An IA5String can contain many different non-text
characters which you could interpret as word delimiters, including space,
period (which is in your example), and many more.

          Tom Gindin

"chandrasekaran natarajan" <[email-masked]> on 04/03/2000
10:11:36 AM

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  ASN.1 , Constructied Encoding

hello,

can any one clear my doubts regarding ASN.1 constructed encoding . Its as
follows

Given a IA5String  value "[email-masked]" and constructed
encoding as

36 13
     16 05 74 65 73 74 31
     16 01 40
     16 07 72 73 61 2e 63 6f 6d

can some one let me know how the first entry 36 is
got ? Is it a Implementor Defined Tag or has it been
Standardised for IA5Strings with Constructed encoding.

And also please let me know  If there is any delimeter for
words apart from @.

Thanks

chandar

Date: Sat, 01 Apr 2000 02:51:46 -0500
To: <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Permanent identifiers in QC

I cannot see any reason for PKIX to specify a permanent identifier.

In my view, it is the job of PKIX (in the son-of-RFC2459 document and the 
companion QC document) to specify the means to bind an identity to a public 
key.  This does not include specifying new methods of specifying an 
identity.  If some Internet application needs a permanent identifier, then 
the needy application should specify it.  Once it is specified, it can be 
used in certificates, just like all of the other name forms that are 
already supported.

Russ

At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
>The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.
>
>This issue is whether we should include a new name form in the
>subjectAltName extension holding  a permanent identifier.
>
>The permanent identifier would then be a name of the subject, unique within
>the issuers domain, that is not reused over time for another subject.
>
>The reason to include such a name form would be that the use of serialNumber
>in DN, or directoryName in subjectAltName extension, does not explicitly
>define this property by itself, unless seen in the light of a defined policy
>etc.
>
>Chair Stephen Kent decided that the decision whether or not to include this
>name form in QC should be taken to the list.
>
>My observation in regards to this is:
>
>1) Adding this name form would add confusion to the QC specification since
>it would overlap use of serialNumber in the DN.
>
>2) Use of DN attributes covers all needs related to identification of the
>subject, and that's all we need to support electronic signatures, at least
>as seen from the EU-directive. And as far I know, this goes for any other
>legal system.
>
>3) Use of DN in combination with either implicit knowledge, use of Directory
>name in the subjectAltname ext, use of a related policy identifier or use of
>information in the qcStatements extension also provide support for use of
>permanent identifiers identified as such.
>
>4) In each and every case raised in favor of this new name form, the benefit
>relates to access control rather than electronic signatures.
>
>5) This is a new input to the discussion, which before adoption must be
>reviewed by the community over some time.
>
>Observation 4 makes this whole discussion outside the scope of QC and in
>combination with the other observations, I would request that the QC is
>moved forward to proposed standard without this new name form.
>
>If PKIX at a later stage would find that a permanent identifier solution, as
>discussed here, is of general value, then this can be moved forward as a
>separate item. At that time we would also know if it should be merged with
>RFC 2459 or the QC profile, if merged at all.
>
>
>
>/Stefan

To: [email-masked]
Date: Mon, 03 Apr 2000 07:11:36 -0700
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: ASN.1 , Constructied Encoding 
Organization: MailCity  (http://www.mailcity.lycos.com:80)

hello,

can any one clear my doubts regarding ASN.1 constructed encoding . Its as follows 

Given a IA5String  value "[email-masked]" and constructed
encoding as

36 13
     16 05 74 65 73 74 31
     16 01 40
     16 07 72 73 61 2e 63 6f 6d

can some one let me know how the first entry 36 is 
got ? Is it a Implementor Defined Tag or has it been
Standardised for IA5Strings with Constructed encoding.

And also please let me know  If there is any delimeter for
words apart from @.

Thanks

chandar

Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

From: [email-masked]
To: [email-masked]
Date: Mon, 3 Apr 2000 09:44:16 -0400
Subject: Re: unsubscribe

unsubscribe

From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: SV: SV: Permanent identifiers in QC
Date: Mon, 3 Apr 2000 21:19:16 +0930
Importance: Normal

Tom,

I support your concerns.

I believe though that what the present solution already handles the issues
that you are addressing. At least as far as it ought to.

The qcStatemsnts extension are there to express policy statements. The
predefined statement is there to express that the certificate follows syntax
and semantics of the QC profile. The optional qualifying information may
hold information that the certificate further adopts to a certain ID-scheme
(such as a specific Italian ID-scheme).

I don't think we should expand that feature beyond that.

What I think we should do know is to move this forward.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]]
> Skickat: den 1 april 2000 09:14
> Till: Stefan Santesson
> Kopia: [email-masked]
> Ämne: Re: SV: Permanent identifiers in QC
>
>
>      I take your point about duplicating the serial number using the
> two-name form I proposed for
> id-qcs-identifierAssignmentAuthority, and I
> hereby withdraw that suggestion.
>      However, assuming that adding name information in the
> qcStatements
> extension contradicts the purpose of that extension, I still
> do not see why
> the one-name version of id-qcs-identifierAssignmentAuthority,
> in which the
> only name in the extension is the name of the identifier assignment
> authority, contradicts the purpose of the extension.  The
> draft's current
> definition says about the name component: "The
> NameRegistrationAuthorities
> component, if present, SHALL contain a name of one or more name
> registration authorities, responsible for registration of
> attributes or
> names associated with the subject."  Why does the assigner of a serial
> number not fit into this definition of a registration authority?
>      Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
> semantics of an existing attribute in a DN within the
> certificate.  How
> does that contradict the statement that a semantics ID "may define
> semantics for all, or for a subgroup of all present attributes and/or
> names"?  Perhaps it would be more in keeping with the spirit
> of the profile
> if there were two different OID's for each of these three
> semantics, one to
> interpret subject name serial numbers and one to interpret subject
> alternate name serial numbers, but that is not a reason not
> to have the
> feature available.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[email-masked]> on 03/31/2000 06:45:54 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
>       <[email-masked]>
> cc:   <[email-masked]>
> Subject:  SV: Permanent identifiers in QC
>
>
>
> Tom,
>
> Using this extension to contain subject name information
> would break the
> intent of this extension.
>
> /Stefan
>
> > -----Ursprungligt meddelande-----
> > Från: [email-masked] [mailto:[email-masked]]
> > Skickat: den 31 mars 2000 09:10
> > Till: Stefan Santesson
> > Kopia: [email-masked]
> > Ämne: Re: Permanent identifiers in QC
> >
> >
> >      I have a counter-proposal.  Given the profile defined for
> > serialNumber, and the definition of SemanticsInformation in
> > draft section
> > 3.2.5.1, a semanticsIdentifier known as
> > id-qcs-identifierAssignmentAuthority should be assigned with
> > the following
> > rules of interpretation: either one or two name registration
> > authorities
> > must be present, and the first one present shall be
> interpreted as the
> > authority governing the name space, while the second
> > (optional) one may
> > contain the serial number or other unique identifier; if
> > there is only one
> > name registration authority present, the unique identifier is
> > assumed to be
> > the serial number attribute of the subject name if there is a
> > serial number
> > attribute in it, and the first serial number attribute
> > encountered in the
> > subject alternate name if there is none in the subject
> name.  Another
> > semanticsIdentifier known as id-qcs-CALocal should be
> > assigned to identify
> > serial numbers assigned locally within the CA.  Optionally, a
> > semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> > assigned with the rule that when one searches for the serial
> > number in the
> > subject name and subject alternate name in the same way as
> > for identifier
> > assignment authorities with only one name registration
> authority, the
> > serial number shall be interpreted as being assigned by the
> > country given
> > in the DN where the serial number is found.
> >
> >           Tom Gindin
> >
> >
> > "Stefan Santesson" <[email-masked]> on 03/30/2000 01:49:44 AM
> >
> > To:   <[email-masked]>
> > cc:
> > Subject:  Permanent identifiers in QC
> >
> >
> >
> > The PKIX meeting in Adelaide raised only 1 issue related to
> > the QC draft.
> >
> > This issue is whether we should include a new name form in the
> > subjectAltName extension holding  a permanent identifier.
> >
> > The permanent identifier would then be a name of the subject,
> > unique within
> > the issuers domain, that is not reused over time for
> another subject.
> >
> > The reason to include such a name form would be that the use of
> > serialNumber in DN, or directoryName in subjectAltName
> > extension, does not
> > explicitly define this property by itself, unless seen in the
> > light of a
> > defined policy etc.
> >
> > Chair Stephen Kent decided that the decision whether or not
> > to include this
> > name form in QC should be taken to the list.
> >
> > My observation in regards to this is:
> >
> > 1) Adding this name form would add confusion to the QC
> > specification since
> > it would overlap use of serialNumber in the DN.
> >
> > [Tom Gindin]   Why would this cause confusion if the name
> > form itself had
> > the same syntax as a DN, and the identity were in the serialNumber
> > attribute of that name?
> >
> > 2) Use of DN attributes covers all needs related to
> > identification of the
> > subject, and that's all we need to support electronic
> > signatures, at least
> > as seen from the EU-directive. And as far I know, this goes
> > for any other
> > legal system.
> >
> > [Tom Gindin]   This does not cover the joint specification of
> > an ID and an
> > assignment authority.  A single ID field with quasi-arbitrary values
> > similar to a serial number has meaning primarily within the
> > scope of its
> > assignment authority.
> >
> > 3) Use of DN in combination with either implicit knowledge, use of
> > Directory name in the subjectAltname ext, use of a related policy
> > identifier or use of information in the qcStatements
> > extension also provide
> > support for use of permanent identifiers identified as such.
> >
> > [Tom Gindin]   No rule for implicit knowledge which would permit an
> > arbitrary RP to recognize a permanent identifier and its assignment
> > authority within a DN (whether subject name or alt name)
> has yet been
> > received with favor.  However, it should be possible to do
> > this using the
> > semanticsIdentifier.
> >
> > 4) In each and every case raised in favor of this new name form, the
> > benefit relates to access control rather than electronic signatures.
> >
> > [Tom Gindin]   Allowing organizations to assign permanent
> > identifiers of
> > this type (most usually, but not necesarily, to employees)
> > has roughly the
> > same impact on signatures as on access control.  If it is
> > assumed that the
> > identity number is assigned by a governmental or quasi-governmental
> > authority, then the serial number is sufficient because my
> > above arguments
> > for assignment authority become irrelevant.
> >
> > 5) This is a new input to the discussion, which before
> > adoption must be
> > reviewed by the community over some time.
> >
> > [Tom Gindin]   It has been under discussion for months.
> >
> > Observation 4 makes this whole discussion outside the scope
> > of QC and in
> > combination with the other observations, I would request that
> > the QC is
> > moved forward to proposed standard without this new name form.
> >
> > [Tom Gindin]   If QC requires that the serial number be
> > assigned either by
> > a governmental or quasi-governmental authority as a permanent
> > identifier or
> > by the CA as a tiebreaker, and that the certificate itself contain
> > somewhere an indicator of whether the name is a permanent
> > identifier or a
> > tiebreaker, then this name form would not be relevant to
> > QC's.  Otherwise
> > it would.
> >
> > If PKIX at a later stage would find that a permanent
> > identifier solution,
> > as discussed here, is of general value, then this can be
> > moved forward as a
> > separate item. At that time we would also know if it should
> > be merged with
> > RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> > /Stefan
> >
>
>
>

Date: Mon, 03 Apr 2000 13:12:34 +0200
From: Arne Nilsson <[email-masked]>
Reply-To: [email-masked]
Organization: Abstracon
To: [email-masked]
Subject: unsubscribe

unsubscribe

Date: Mon, 3 Apr 2000 13:58:04 +0300
From: Maxim Masiutin <[email-masked]>
Organization: RIT Research Labs
To: [email-masked]
Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.

Hello!

   I tried to submit "Incorporaion of PGP Certificates into X.509v3
   Certificates" draft, but it was IETF meeting. I post my draft here
   until IETF will be ready to accept new drafts. You comments are very
   welcome.

Internet Draft                                      M. Masiutin
                                                    RITLABS
April 3, 2000
expires in six months

   Incorporaion of PGP Certificates into X.509v3 Certificates.

   Copyright 2000 by The Internet Society. All Rights Reserved.

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts. Internet-Drafts are draft
   documents valid for a maximum of six months and may be updated,
   replaced, or obsoleted by other documents at any time. It is
   inappropriate to use Internet-Drafts as reference material or to cite
   them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   There were currently no described provisions to convert from an
   X.509v3 certificate to a PGP Certificate and vice versa because of
   format of data being signed differ in these two standards. This
   document defines a new X.509v3 certificate extension called pgpKey
   that holds a verbatim PGP Certificate, making such conversion
   possible.

   This draft is being discussed on the "[email-masked]" mailing
   list. To join the list, send a message to <[email-masked]>
   with the single word "subscribe" in the body of the message. Also,
   there is a Web site for the mailing list at
   <http://www.imc.org/ietf-pkix>.

Definitions, Abbreviations, and Symbols

   UserID

     Data that is intended to represent the name and email address of
     the key holder.

   KeyMaterial
  
     Public key material, i.e. data used as a key in encryption and/or
     signature checking operation.

   PubKey

     KeyMaterial and one or more associated user UserIDs.

   PGPCert

     Also referred as Transferable PGP Certificate. Signed PubKey; after
     each UserID, zero or more signatures (certifications) follow.

   X509Cert

     X.509v3 certificate, as defined in [X509] secion 4.

   X509NativeCert

     X.509v3 certificate, without PGPKey extension.
   
   X509PGPCert

     X.509v3 certificate, with PGPKey extension.

   S/MIME

     Secure/Multipurpose Internet Mail Extensions
     
   PGP/MIME

     Pretty Good Privacy/Multipurpose Internet Mail Extensions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD].

   The key words starting with X509- are defined in [X509] without X509-
   prefix.

Introduction

   There are currently two actively proposed methods for providing
   security services for e-mail: S/MIME and PGP/MIME. Both methods
   are based on RFC's that have IETF standards track status.

   PGP/MIME is based on [OpenPGP] message and certificate formats that
   were derived from [PGPOld] formats. These formats were created from
   scratch, and use simple binary encoding. [PGPOld] defines [RSA],
   [IDEA] and [MD5] algorithms as mandatory. OpenPGP makes these
   algorithms optional.

   S/MIME was originally developed by RSA Data Security, Inc. It is
   based on the [CMS] data format for the messages, and the [X509]
   format for certificates. [CMS] is a successor of [PKCS7]. [PKCS7] is
   based on the [ASN1] DER format for data.

   Of course, having two protocols that do the same thing is much worse
   than having one. Although they offer similar services to users, the
   two protocols have very different formats. Further, and more
   important to users, they have different formats for their
   certificates. This means that not only can users of one protocol not
   communicate with the users of the other, they also cannot share
   authentication certificates.

   This document defines a combined format of certificates. It also
   proposes a solution for applications that support both S/MIME and
   PGP/MIME.

   Applications that support both S/MIME and PGP/MIME get a possibility
   to have a single repository that keeps not only X509NativeCerts but
   also X509PGPCerts converted from PGPCerts. No separate
   [OpenPGP]-compatible public keyrings is needed in that case, thus
   such keyrings as well as single PGPCerts may be imported from and
   exported to that repository. There is no need of two different user
   interfaces for X509Cert repository and [OpenPGP]-keyring. Users of
   such applications may not even know the differences between S/MIME
   and PGP/MIME, X509Cert and PGPCert.

Implementing this specification
   
   Implementation of this specification must be done in such manner that
   it should not contradict with provisions of [OpenPGP], [X509] and
   [ESS].

Certificate Extension

   This document defines a new X509Cert extension called pgpKey that
   holds a verbatim PGPCert. Same KeyMaterial and keyholder's data is
   packed in X509Cert and PGPCert, but different packing methods are
   used, to conform both [OpenPGP] and [X509] standards.

   Defined extension is in full conformance with X509-Extension and MUST
   be non-critical. As each extension includes an associated object
   identifier (OID) and an [ASN1] structure, pgpKey extension has the
   following [ASN1] definition:

   id-ce-pgpKey OBJECT IDENTIFIER  ::= {??????????}

   pgpKey  ::= SEQUENCE {
     pgpKeyContents        pgpKeyContentsChoice
   }

   pgpKeyContentsChoice  ::= CHOICE
     pgpKeySingleVersion     [0] OCTET STRING
     pgpKeyAlternative       [1] pgpKeyAlternativeVersions }

   pgpKeyAlternativeVersions  ::= SEQUENCE
     pgpKeySignV3           OCTET STRING,
     pgpKeySignV4           OCTET STRING}

   If an OpenPGP certificate is available in two versions, [PGPOld]
   (for compatibility with old applications) and [OpenPGP] (allowing
   signature extensions), pgpKeyAlternative should be choosen. Otherwise,
   pgpKeySingleVersion should be choosen.

Data Being Certified

   There are some restrictions on X509-subject structure for
   X509PGPCert. X509-subject MUST contain a single DistinguishedName in
   an X509-RDNSequence. X509-RelativeDistinguishedName MUST contain a
   single occurrence of type X509-emailAddress, X509-id-at-name, and
   X509-id-at-commonName, which are defines in [X509]. Value of
   X509-emailAddress MUST match X509-subjectAltName extension. No UTF-8
   strings are allowed. No characters that require quoting in [RFC822]
   e-mail address are allowed by this specification, although there are
   no restrictions on format of other data containded in
   X509-RelativeDistinguishedName. Value of X509-emailAddress MUST match
   X509-id-at-commonName. Incorporated OpenPGP certificate MUST have at
   least one UserID packet bound to the same public key which is packed
   into X509-SubjectPublicKeyInfo. Although OpenPGP format makes no
   restriction on contents of UserID packet (chapter 5.11 of [OpenPGP]),
   this specification does define, in a form of [ABNF]-like notation

   User-ID = X509-id-at-name " <" X509-emailAddress ">"

   Contents of UserID of incorporated PGPCert MUST be formed by a rule
   described above. This UserID must be associated with the same
   KeyMaterial as in X509-SubjectPublicKeyInfo, and signed by the same
   issuer's key. Issuer's key is identified by AuthorityKeyIdentifier
   extension. Other UserIDs may also exist in an incorporated PGPcert.

Choosing between pgpKeySingleVersion and pgpKeyAlternativeVersions

   When pgpKey extension is assembled for a new X509Cert certificate
   that is created along with a new PGPCert, and it is possible to
   produce a PGPCert readable by [PGPOld]-applications,
   pgpKeyAlternativeVersions should be choosen. PubKey should be signed
   using Version 3 and Version 4 OpenPGP Signature Packets, resulting
   two PGPCerts. This can be done, for example, by a certification
   authority using data presented in a certification request, or by an
   end-user application that generates a self-signed certificate.

   When pgpKey certificate extension is created from an existing
   PGPCert, or when it is unable to produce a PGPCert readable by
   [PGPOld]-applications (e.g. [RSA] algorithm is unavailable or
   undesirable), pgpKeySingleVersion should be choosen. Such PgpCert
   should be put inside OCTET STRING of pgpKeySingleVersion, regardless
   versions of signature packets used. Unnecessary or untrusted UserIDs
   and/or signatures may be stripped. This can be done, for example, by
   an applications that support both S/MIME, PGP/MIME, when a user
   imports a PGPCert taken from a PGP keyserver into a X509Cert
   repository of his/her e-mail client.

pgpKeyAlternative

   pgpKeyAlternative holds two versions of OpenPGP certificate, one of
   which MUST be in full conformance with [PGPOld], other SHOULD contain
   OpenPGP Signature Packets Version 4 with possible subpackets.

   As [RSA] algorithm is mandatory by [PGPOld], pgpKeyAlternative may
   only occur in X509Certs that use [RSA] public keys, i.e.
   signatureAlgorithm must be [RSA]-based. Examples are [RSA]-based
   signature algorithm identifiers ([ASN1] OIDS) are
   md2WithRSAEncryption, md5WithRSAEncryption and sha1WithRSAEncryption
   (see Security Issues chapter).

   KeyMaterial, associated UserIDs, signing keys, and all other data,
   such as number of UserIDs and signatures, as well as order of packets
   above mentioned, used to produce a PGPCert for pgpKeySignV3 MUST also
   be used without a change or addition to produce a PGPCert for
   pgpKeySignV4. OpenPGP certificate of pgpKeySignV4 may contain
   signature subpacket(s) that are not allowed by version 3 of OpenPGP
   Signature Packet Format.

   To produce a valid pgpKeyAlternative, [RSA] KeyMaterial and
   associated User IDs should be:

   1) signed using PGP Signature Packet Version 3 as defined in Section
   5.2.2 of [OpenPGP] by means of algorithms required by [PGPOld] ([RSA]
   and [MD5]) making it readable by [PGPOld]-applications. Resulting
   PGPCert should be put inside OCTET STRING of pgpKeySignV3.

   2) signed using OpenPGP Signature Packet Version 4 with all possible
   subpackets as defined in Section 5.2.3 of [OpenPGP], making it
   readable by [OpenPGP]-applications. The same [RSA] KeyMaterial as for
   previous step should be used to produce a signature, but a different
   hashing method is allowed. Resulting OpenPGP certificate should put
   be inside OCTET STRING of pgpKeySignV4.

Converting from existing PgpCert
   
   Primary KeyMaterial and primary UserID of a given PgpCert are used to
   form the X509-subject and X509-subjectPublicKeyInfo members of
   X509-TBSCertificate. An application may display a dialog of choices,
   allowing user to select which UserID is primary. An application
   should also validate signatures of UserIDs. Selected UserId is
   parsed, according to [RFC822], to extract a user name and an e-mail
   address. If it was unable to extract a valid e-mail address, an
   application shouldn't convert given PgpCerts. Extracted data should
   be used to produce a valid X509-subject structure, as defined in
   "Data Being Certified" chapter.

   If it was unable to extract a valid user name, but an e-mail was
   extracted, an application should copy this e-mail string to all
   fields containing user name that are mandatory by this document or
   may be mandatory by other documents.

Security Considerations

   All security considerations from [OpenPGP], [X509] and [ESS] apply to
   applications that use procedures described in this document. Security
   rules for X509PGPCert are the same as for a pair of a separate
   PGPCert and a separate X509NativeCert.

   As md2WithRSAEncryption is referred in this document, it SHOULD not
   be used. As about md5WithRSAEncryption and sha1WithRSAEncryption, the
   [MD5] hash algorithm has been found to have weaknesses
   (pseudo-collisions in the compress function) that make some people
   deprecate its use. They consider the [SHA1] algorithm better.

References

   [ASN1]

      CCITT Recommendation X.208: Specification of Abstract Syntax
      Notation One (ASN.1), 1988.

   [SHA1]

     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

   [IDEA]

     Lai, X, "On the design and security of block ciphers", ETH Series
     in Information Processing, J.L. Massey (editor), Vol. 1,
     Hartung-Gorre Verlag Knostanz, Technische Hochschule (Zurich), 1992

   [MD5]

     The MD5 Message-Digest Algorithm. R. Rivest. April 1992. RFC1321.

   [RSA]

     PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski,
     J. Staddon. October 1998. RFC2437.

   [RFC2234]

     Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P.
     Overell. November 1997. RFC2234.

   [RFC822]

     Standard for the format of ARPA Internet text messages. D. Crocker.
     13 August 1982. STD0011, RFC882.

   [PGPOld]

     PGP Message Exchange Formats. D. Atkins, W. Stallings & P.
     Zimmermann. August 1996. RFC1991.

   [OpenPGP]

     OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
     Thayer. November 1998. RFC2440.

   [X509]

     Internet X.509 Public Key Infrastructure Certificate and CRL
     Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999.
     RFC2459.

   [CMS]
   
     Cryptographic Message Syntax. R. Housley. June 1999. RFC2630.

   [MUSTSHOULD]
   
     Key words for use in RFCs to Indicate Requirement Levels. S.
     Bradner. March 1997. BCP0014, RFC2119.
     
   [ESS]

     Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June
     1999. RFC2634.

   [PKCS7]

     PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski.
     March 1998. RFC2315.

Author's Address

   Maxim Masiutin
   RITLABS S.R.L.
   180 Stefan cel Mare
   Chisinau MD2004
   Republic of Moldova
   [email-masked]
   fax: +373-2-246530

Full Copyright Statement

Copyright (C) The Internet Society 2000.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   

-- 
Max Masyutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

From: "Valery Smyslov" <[email-masked]>
Organization: TWS
To: [email-masked]
Date: Mon, 3 Apr 2000 14:06:15 +0400
Subject: Certificate path processing
Priority: normal

Hi,

I have a couple of questions regarding path processing. draft-ietf-
pkix-new-part1-01.txt states, that end entity may directly trust not 
only top CA in the hierarchy, but instead, some subordinate CA (for 
example, CA of end enity's own domain) and that it makes no 
difference to path validation algorithm. However, it seems to may 
make difference to path validation results. Consider the following 
example. Let's have CA hierarchy with top CA and two subordinate CA. 
Top CA imposes some constraints on first subordinate (for example, 
name constraint) while this subordinate imposes no constraints on its 
"son". In this situation, if end entity uses top CA or first 
subordinate as root CA, this constraints will be taken into 
consideration, while if it uses second subordinate CA as root CA - 
won't. Is it correct?
And another question: if end entity directly trusts some intermediate 
certificate in the path, does it means, that it may trust all 
certificates in the path, not only certificates below directly 
trusted, but also including certificates above it, up to the top? If 
the answer is "yes", it seems that the abovementioned possible 
difference in path validation results is incorrect. Am I wrong?

Thanks,
Valera.

Date: Mon, 03 Apr 2000 08:47:50 +0900
From: JeeyeonKim <[email-masked]>
To: [email-masked]
Subject: unsubscribe

unsubscribe

From: "Nadir Asef" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: unsubscribe
Date: Sun, 2 Apr 2000 12:40:47 -0300

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01BF9CA0.AB69C7C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_0023_01BF9CA0.AB69C7C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>unsubscribe</DIV></DIV></BODY></HTML>

------=_NextPart_000_0023_01BF9CA0.AB69C7C0--

From: "Felix Nadir Asef" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: unsubscribe
Date: Sun, 2 Apr 2000 12:34:46 -0300

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BF9C9F.D49DAEA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_0015_01BF9C9F.D49DAEA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>unsubscribe</DIV></BODY></HTML>

------=_NextPart_000_0015_01BF9C9F.D49DAEA0--

From: Erik Andersen <[email-masked]>
To: "'Sharon Boeyen'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'500 list'" <[email-masked]>
Cc: "'Blake Greenlee'" <[email-masked]>, "'Hoyt Kesterson'" <[email-masked]>
Subject: RE: X.509 approved - see ITU-T press release
Date: Sat, 1 Apr 2000 21:12:02 +0200
Organization: Andersen's L-Service

Hi Sharon,

Congratulation. I just do not understand why your name was not mentioned in the press release.

Erik Andersen
CEN/ISSS/WS-DIR Chairman
Mobile: +45 20 97 14 90
E-mail;  [email-masked]
Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm

-----Original Message-----
From:	Sharon Boeyen [SMTP:[email-masked]]
Sent:	31. marts 2000 18:43
To:	[email-masked]'; [email-masked]'; '500 list'
Cc:	'Blake Greenlee'; 'Hoyt Kesterson'
Subject:	RE: X.509 approved - see ITU-T press release

FYI:

http://www.itu.int/ITU-T/itu-t_news/sg7_x509_press.htm

Date: Sat, 1 Apr 2000 01:12:47 -0700
To: OSI Directory List <[email-masked]>, [email-masked], ABA Information Security Committee <[email-masked]>
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: no trees were hurt in the making of this revision

In 1988 a magazine reported the publishing of the CCITT (now ITU) 1988 recommendations as "forests fall as CCITT moves to publish".

Only electrons will perish as a result of my telling you that since we found a few asn.1 errors, we decided to produce a corrected version of X.509/9594-8.

you can find the replacement text in word 8 and pdf formats at 

  ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV2.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV2.pdf

this text is unofficial until iso approves it. iso will begin a final amendment ballot soon. the ballot period lasts for two months.

note that when the text is approved and available for purchase, it will be removed from this server.

  hoyt