RE: Cert Path Validation Bug in pkix-new-part1-00

[Santosh Chokhani <[e-mail]>]

John:

I have been scanning this thread.

Please note that there is no such thing as parameters in the RSA.  The
public key is e, n.  n is the composite and is not common to all the folks.
While there are some popular values of e such as 3 and 2**16 + 1, it is the
encryption exponent and not a parameter a la DH or DSS which can be a common
to a community and in DH's case is required to be common for the crypto math
to work.

Thus, in my mind from pure cryptographic algorithm and from X.509 viewpoints
talking about RSA parameters is a contradiction in terms.

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Tuesday, February 29, 2000 11:29 AM
To: pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00


Stephen,

I agree that the handling of RSA parameters isn't clearly stated in the
pkix-new-part1-00 cert path validation procedures.  Recommend that the
following text be added to the description of the
working_public_key_parameters variable in section 6.1.2, bullet (i): "The
RSA algorithm parameter is ASN.1 encoded in the RSAPublicKey SEQUENCE
conveyed in the subjectPublicKeyInfo subjectPublicKey BIT STRING.  The RSA
algorithm parameter is always present in RSAPublicKey (algorithm parameter
inheritance is not used with RSA).  The certification path validation
procedures described in this section specify that the
working_public_key_parameters variable is set to NULL when associated with
an RSA working_public_key.  This strategy is used because the RSA algorithm
parameter is always bundled with the RSA public key in the RSAPublicKey
SEQUENCE."  

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 



Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA22664 for <[e-mail]>; Tue, 29 Feb 2000 16:24:47 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <F625612Q>; Tue, 29 Feb 2000 19:01:22 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E58F737@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Pawling, John'" <[e-mail]>, pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Tue, 29 Feb 2000 19:01:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

John:

I have been scanning this thread.

Please note that there is no such thing as parameters in the RSA.  The
public key is e, n.  n is the composite and is not common to all the folks.
While there are some popular values of e such as 3 and 2**16 + 1, it is the
encryption exponent and not a parameter a la DH or DSS which can be a common
to a community and in DH's case is required to be common for the crypto math
to work.

Thus, in my mind from pure cryptographic algorithm and from X.509 viewpoints
talking about RSA parameters is a contradiction in terms.

-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Tuesday, February 29, 2000 11:29 AM
To: pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00


Stephen,

I agree that the handling of RSA parameters isn't clearly stated in the
pkix-new-part1-00 cert path validation procedures.  Recommend that the
following text be added to the description of the
working_public_key_parameters variable in section 6.1.2, bullet (i): "The
RSA algorithm parameter is ASN.1 encoded in the RSAPublicKey SEQUENCE
conveyed in the subjectPublicKeyInfo subjectPublicKey BIT STRING.  The RSA
algorithm parameter is always present in RSAPublicKey (algorithm parameter
inheritance is not used with RSA).  The certification path validation
procedures described in this section specify that the
working_public_key_parameters variable is set to NULL when associated with
an RSA working_public_key.  This strategy is used because the RSA algorithm
parameter is always bundled with the RSA public key in the RSAPublicKey
SEQUENCE."  

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 


Received: from snoopy.cit.nih.gov (snoopy.cit.nih.gov [156.40.8.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15768 for <[e-mail]>; Tue, 29 Feb 2000 11:56:14 -0800 (PST)
Received: from localhost (rmalick@localhost) by snoopy.cit.nih.gov (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id OAA64021 for <[e-mail]>; Tue, 29 Feb 2000 14:56:40 -0500 (EST)
Date: Tue, 29 Feb 2000 14:56:39 -0500 (EST)
From: Robert Malick <[e-mail]>
Sender: [e-mail]
To: "[e-mail]" <[e-mail]>
Subject: UI DN as certificate subject was RE: Straw Poll: SerialNumber definition
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

It seems in the discussion of placing the uniquely identifiying DN in the
SubjectAltName everyone is assuming that one needs something other than
that as the certificate subject.

Is it totally illegal or just not good practice for some reason to have a
uniquely identifying DN as a certificate subject and have the application
find other commentary attributes like displayable name (e.g., cn)
by accessing the entry in the directory for that subject DN?

For example,

Certificate Subject: sn=0001000018, o=acme, c=us

An application when looking up that DN in the directory will find:

dn: sn=0001000018, o=acme, c=us
cn: Joe Smith
...

The application can display what it likes of this particular certificate
identity. Most likely the application will access the directory for other
things for certificate path processing so I don't see this as anything out
of the ordinary.

Also, this allows one to assign identity without the overhead of
revoking certificates if these commentary attributes should change (e.g.,
cn).

Can someone tell me why it seems that one should assume that commentary
attributes must be in the subject DN of the certificate?

	Robert Malick
	National Institutes of Health




Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12892 for <[e-mail]>; Tue, 29 Feb 2000 08:29:58 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <1JW6P1HV>; Tue, 29 Feb 2000 11:29:31 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Tue, 29 Feb 2000 11:29:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

I agree that the handling of RSA parameters isn't clearly stated in the
pkix-new-part1-00 cert path validation procedures.  Recommend that the
following text be added to the description of the
working_public_key_parameters variable in section 6.1.2, bullet (i): "The
RSA algorithm parameter is ASN.1 encoded in the RSAPublicKey SEQUENCE
conveyed in the subjectPublicKeyInfo subjectPublicKey BIT STRING.  The RSA
algorithm parameter is always present in RSAPublicKey (algorithm parameter
inheritance is not used with RSA).  The certification path validation
procedures described in this section specify that the
working_public_key_parameters variable is set to NULL when associated with
an RSA working_public_key.  This strategy is used because the RSA algorithm
parameter is always bundled with the RSA public key in the RSAPublicKey
SEQUENCE."  

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26338 for <[e-mail]>; Tue, 29 Feb 2000 02:32:47 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA20688; Tue, 29 Feb 2000 10:32:45 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020563; Tue, 29 Feb 00 10:31:47 GMT
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA18082; Tue, 29 Feb 2000 10:31:46 GMT
Message-ID: <[e-mail]>
Date: Tue, 29 Feb 2000 10:31:39 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pawling, John" <[e-mail]>, pkix <[e-mail]>
CC: xme <[e-mail]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi John,

> I respectfully disagree with your comment that
> my new text prevents parameter inheritance across an "algorithm gap".  
...
> Therefore, the cert path verification software does not need to set the
> working_public_key_parameters to the RSA algorithm parameter value

Fair enough, but that isn't clearly stated, so maybe there should be 
text about special handling of ASN.1 NULL ('0500'H) as a parameter? 
But in any case...

> I agree with you that cert 3 in your example is invalid because the DSA
> parameters must be present if the cert is signed using RSA.  The
> verification of cert 4 would fail because working_public_key_parameters
> would be set to NULL based on cert 3.  I agree with your recommended text:
> "if the signing algorithm and subject public key algorithms in a certificate
> differ, then the issuer MUST include all algorithm parameters in the
> subjectPublicKeyInfo as parameter inheritance is not supported in such
> cases."

...that was the meat of the posting, so we do agree!

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05023 for <[e-mail]>; Mon, 28 Feb 2000 19:55:26 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 8A9B315533; Mon, 28 Feb 2000 22:54:52 -0500 (EST)
Received: by haggis.ma.certco.com (Postfix, from userid 1079) id 672177C0E8; Mon, 28 Feb 2000 22:54:52 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id 5EE78744C6; Mon, 28 Feb 2000 22:54:52 -0500 (EST)
Date: Mon, 28 Feb 2000 22:54:52 -0500 (EST)
From: Rich Salz <[e-mail]>
To: Ambarish Malpani <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> If a. is true, then you really need to send the whole cert to the
> VA and have the VA tell you if it was actually issued.

Or a hash of the cert.  The CA could generate an "issued list",
perhaps a signed sequence of hashes, and the OCSP Responder
could see if the hash the client sent was in the CA's whitelist.
(Unfortunately that area is rife with patents.)

> If b. then all you need to do is verify the signature on the cert
> and you are done - having the VA check for the cert in a directory
> is useless.

No -- see below.

> If I can get a level of security by relying on 1 component, I would
> prefer that solution, to one where I get the same level of security
> by relying on the security aspects of 2 components - the more
> pieces you need to be operated securely, the more insecure you
> solution.

Not necessarily: it depends on what "securely" really means.  If the
two components are under different domains of control, then you could
get greater security even if the level on each component is low.
In the above case, if someone has bribed a CA's overnight operator to
improperly sign a certificate, they'd presumably now have to spend
twice the amount of money to get the cert into the directory.  The
directory could say "we only accept certs after getting a phone
call from Mike Jones between 9am and 5pm."

	/r$



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23137 for <[e-mail]>; Mon, 28 Feb 2000 14:15:42 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLX8TN>; Mon, 28 Feb 2000 14:06:16 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Mon, 28 Feb 2000 14:06:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Rich,
    Answers inline.

Ambarish

> -----Original Message-----
> From: Salz, Rich [mailto:[e-mail]]
> Sent: Monday, February 28, 2000 2:03 PM
> To: 'Ambarish Malpani'; '[e-mail]'
> Subject: RE: German Law and OCSP
> 
> 
> >c. The responder (VA) verify that the cert was contained in "the"
> directory.
> 
> Is VA now a generic term for OCSP responder?  I thought you 
> guys trademarked
> it. Be careful, you don't want to go the way of kleenex... :)

Actually, I am not sure that we have done so - good idea :-)

> 
> >ANOTHER CERTIFICATE WITH THE SAME
> >SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!
> 
> How so?  Since the certID includes the issuerNameHash, it 
> identifies the
> issuer, and since the issuer doesn't re-use serial#'s,...  There are
> performance impliciations -- it might require a directory to index by
> HASH(issuer_dn) -- but that seems surmountable.  There are 
> other approaches,
> such as having an OCSP responder which gets both certs and 
> crl's, not just
> revocation data.  (Modesty prevents me from naming names :)

Yes, Rich - what you say would be true if nobody could forge a
CA's signature, but in that case the person making the request
could just verify the signature on the cert itself and you would
not get any added benefit from having the VA look up the directory
for the existance of the cert.

The point I have been trying to make is:
a. Either you think the CA's signature can be forged
b. Or, you don't.

If a. is true, then you really need to send the whole cert to the
VA and have the VA tell you if it was actually issued.

If b. then all you need to do is verify the signature on the cert
and you are done - having the VA check for the cert in a directory
is useless.

> 
> It also puts the directory into part of the trusted base.  In general
> directories aren't put there, but if that's what the lawyers 
> wrote, then
> we techies can only comply.


Again, as a techie, I like to make my own life as simple as I can.
If I can get a level of security by relying on 1 component, I would
prefer that solution, to one where I get the same level of security
by relying on the security aspects of 2 components - the more
pieces you need to be operated securely, the more insecure you
solution.

Hope this clarifies things,
Regards,
Ambarish 


Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22813 for <[e-mail]>; Mon, 28 Feb 2000 14:08:36 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <1JW63VL4>; Mon, 28 Feb 2000 17:08:02 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: pkix <[e-mail]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Mon, 28 Feb 2000 17:08:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,

Thank you for your response.  I respectfully disagree with your comment that
my new text prevents parameter inheritance across an "algorithm gap".  As
stated in RFC 2459, Section 7.3.1, the RSA algorithm parameter is ASN.1
encoded in the RSAPublicKey SEQUENCE carried in the subjectPublicKeyInfo
subjectPublicKey BIT STRING.  Furthermore, the RSA algorithm parameter is
always present in RSAPublicKey (algorithm parameter inheritance is never
used with RSA).  The pkix-new-part1-00 cert path validation procedures never
specify that the working_public_key_parameters variable be set to the
algorithm parameter associated with an RSA public key.  This is true because
the subjectPublicKeyInfo algorithm field associated with an RSA public key
always contains NULL parameters.  

I believe that the section was purposely written in such a manner.  I agree
with that strategy since the RSA algorithm parameter is encoded within
RSAPublicKey and is always present.  Typically, the cert path verification
software passes the RSAPublicKey SEQUENCE to a low-level crypto library
which decodes the SEQUENCE into the modulus and publicExponent components.
Therefore, the cert path verification software does not need to set the
working_public_key_parameters to the RSA algorithm parameter value, because
the low-level crypto library always has access to the RSA algorithm
parameter in the RSAPublicKey SEQUENCE.  Given that assumption, the
pkix-new-part1-00 cert path validation procedures (with my recommended text
included) correctly support parameter inheritance across an "algorithm gap".
This assumption should be included in the definition of
working_public_key_parameters in the pkix-new-part1-00 cert path validation
section. 

If people disagree with this assumption, then the pkix-new-part1-00 cert
path validation procedures need to be re-written to specify that the
working_public_key_parameters variable must be set to the RSA algorithm
parameter present in RSAPublicKey.  This will cause the procedures to be
algorithm specific (rather than generic).

In your example below, the verification of the RSA signature of cert 3 will
succeed because the cert path verification code knows that the RSA algorithm
parameter is encoded within RSAPublicKey and it ignores the
working_public_key_parameters (set to NULL at that point).

I agree with you that cert 3 in your example is invalid because the DSA
parameters must be present if the cert is signed using RSA.  The
verification of cert 4 would fail because working_public_key_parameters
would be set to NULL based on cert 3.  I agree with your recommended text:
"if the signing algorithm and subject public key algorithms in a certificate
differ, then the issuer MUST include all algorithm parameters in the
subjectPublicKeyInfo as parameter inheritance is not supported in such
cases."

-John Pawling

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Monday, February 28, 2000 5:59 AM
To: John Pawling; pkix
Cc: xme; RussHousley; TimPolk
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00



John,

Your new text seems to prevent parameter inheritance 
across an "algorithm gap", e.g. the following couldn't 
verify (because we set the working parms to "null"
during verification of cert 2, so cert 3 will fail):

1: [ top-CA, top-CA, DSA + parms] (self-)signed with DSA/SHA1
2: [ mid-CA, top-CA, RSA + NULL ] signed with DSA/SHA1
3: [ low-CA, mid-CA, DSA (no params) ] signed with RSA
4: [ end-entity, low-CA, whatever] signed with DSA/SHA1

(the notation is [ subject, issuer, subj.public key] signing-alg )

I've no problem with this, but it might not be what an 
implementer would do, so should it be made explicit?

One way to do this might be to include a statement like
"if the signing algorithm and subject public key algorithms
in a certificate differ, then the issuer MUST include
all algorithm parameters in the subjectPublicKeyInfo
as parameter inheritance is not supported in such 
cases".

This would make cert 3 above non-conformant.

The text could go into section 4.1.2.7 or section 7, or maybe
both.

Regards,
Stephen.

"Pawling, John" wrote:
> 
> All,
> 
> There is a bug in the certification path validation Wrap-up procedures
> section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
> <draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
> public key is used to verify an end-entity cert containing an RSA public
> key, then the current Wrap-up procedure does not properly set the
> working_public_key_parameters variable to NULL.  With the current
procedure,
> the working_public_key_parameters is still set to the issuer's DSS
algorithm
> parameters.  Recommend the following change to section 6.1.5:
> 
> OLD:  (d) 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.
> 
> NEW:  (d) 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,
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.
> 
> ============================================
> John Pawling, Director - Systems Engineering
> J.G. Van Dyke & Associates, Inc;
> a Wang Government Services Company
> [e-mail]
> ============================================

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22564 for <[e-mail]>; Mon, 28 Feb 2000 14:03:33 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 29A9615531; Mon, 28 Feb 2000 17:02:54 -0500 (EST)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 70BF67C0E8; Mon, 28 Feb 2000 17:02:54 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <FXALBJW1>; Mon, 28 Feb 2000 17:02:45 -0500
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Mon, 28 Feb 2000 17:02:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

>c. The responder (VA) verify that the cert was contained in "the"
directory.

Is VA now a generic term for OCSP responder?  I thought you guys trademarked
it. Be careful, you don't want to go the way of kleenex... :)

>ANOTHER CERTIFICATE WITH THE SAME
>SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!

How so?  Since the certID includes the issuerNameHash, it identifies the
issuer, and since the issuer doesn't re-use serial#'s,...  There are
performance impliciations -- it might require a directory to index by
HASH(issuer_dn) -- but that seems surmountable.  There are other approaches,
such as having an OCSP responder which gets both certs and crl's, not just
revocation data.  (Modesty prevents me from naming names :)

It also puts the directory into part of the trusted base.  In general
directories aren't put there, but if that's what the lawyers wrote, then
we techies can only comply.



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15507 for <[e-mail]>; Mon, 28 Feb 2000 08:27:14 -0800 (PST)
Received: from [207.123.171.35] (coldhcp3-35.bbn.com [207.123.171.35]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA16056; Mon, 28 Feb 2000 11:27:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b4e04fc23a44@[128.33.238.74]>
In-Reply-To: <004c01bf8037$3387fd10$[e-mail]>
References: <004c01bf8037$3387fd10$[e-mail]>
Date: Mon, 28 Feb 2000 11:17:48 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

What part of my comments re the context in which this WG operates 
were unclear to you?  I already pointed out that we have, in 
producing 2459, been willing to disparage common practice wrt misuse 
of DNs.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15506 for <[e-mail]>; Mon, 28 Feb 2000 08:27:14 -0800 (PST)
Received: from [207.123.171.35] (coldhcp3-35.bbn.com [207.123.171.35]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA16059; Mon, 28 Feb 2000 11:27:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b4e0505c5e3c@[128.33.238.74]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 28 Feb 2000 11:28:29 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tom,

My favorable reaction to this proposal is based on the assumption 
that the SubjectAltName would be a valid DN, and thus one need not 
impose any special interpretation on the use of serialNumber in that 
name.  So, for example, I would expect an name of the form: C=SE, 
O=National ID Card System, SerialNumber = 123456789.  This is 
consistent with the usual definition of the SubjectAltName extension, 
and merely suggests that this DN is an alias for the other entry in 
the DIT.

Remember, my suggestion was an effort to respond to a perceived 
special case ID requirement, which is not one of my favorite topics 
in the first place ...

Steve


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11020 for <[e-mail]>; Mon, 28 Feb 2000 04:10:56 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA15910; Mon, 28 Feb 2000 11:02:28 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015299; Mon, 28 Feb 00 10:58:40 GMT
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA27054; Mon, 28 Feb 2000 10:58:39 GMT
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2000 10:58:41 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Pawling <[e-mail]>, pkix <[e-mail]>
CC: xme <[e-mail]>, RussHousley <[e-mail]>, TimPolk <[e-mail]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Your new text seems to prevent parameter inheritance 
across an "algorithm gap", e.g. the following couldn't 
verify (because we set the working parms to "null"
during verification of cert 2, so cert 3 will fail):

1: [ top-CA, top-CA, DSA + parms] (self-)signed with DSA/SHA1
2: [ mid-CA, top-CA, RSA + NULL ] signed with DSA/SHA1
3: [ low-CA, mid-CA, DSA (no params) ] signed with RSA
4: [ end-entity, low-CA, whatever] signed with DSA/SHA1

(the notation is [ subject, issuer, subj.public key] signing-alg )

I've no problem with this, but it might not be what an 
implementer would do, so should it be made explicit?

One way to do this might be to include a statement like
"if the signing algorithm and subject public key algorithms
in a certificate differ, then the issuer MUST include
all algorithm parameters in the subjectPublicKeyInfo
as parameter inheritance is not supported in such 
cases".

This would make cert 3 above non-conformant.

The text could go into section 4.1.2.7 or section 7, or maybe
both.

Regards,
Stephen.

"Pawling, John" wrote:
> 
> All,
> 
> There is a bug in the certification path validation Wrap-up procedures
> section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
> <draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
> public key is used to verify an end-entity cert containing an RSA public
> key, then the current Wrap-up procedure does not properly set the
> working_public_key_parameters variable to NULL.  With the current procedure,
> the working_public_key_parameters is still set to the issuer's DSS algorithm
> parameters.  Recommend the following change to section 6.1.5:
> 
> OLD:  (d) 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.
> 
> NEW:  (d) 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, 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.
> 
> ============================================
> John Pawling, Director - Systems Engineering
> J.G. Van Dyke & Associates, Inc;
> a Wang Government Services Company
> [e-mail]
> ============================================

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27386 for <[e-mail]>; Fri, 25 Feb 2000 23:59:57 -0800 (PST)
Received: from mega (t4o69p116.telia.com [62.20.145.236]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA16233; Sat, 26 Feb 2000 09:02:20 +0100
Message-ID: <004c01bf8037$3387fd10$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Sat, 26 Feb 2000 08:55:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA27390

Steve,

<snip>

>Finally, Anders, this does nothing to address your more recent desire to impose the
>concept of a naming domain on DNs. Since DNs exist in the context of a DIT, which
>establishes naming domains via hierarchic refinement (the same way the DNS does), 
> suspect that what you are asking for here is not consistent with the use of a DN anyway. 
>Maybe we're back at the "have your cake and eat it too" stage for this issue.

>Steve

In the X500-world DNs exist in the context of a DIT.  However, most PKIs are
X500-compliant only with respect to certificate format .   Also I doubt that many X500-
compliant systems use certificates without fully qualified DNs.  I.e. my request
probably matches >90% of all certificates.  That figure justifies some kind of support.
Now I'll go back a continue eating that cake.  It tastes fine!

Anders






Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05853 for <[e-mail]>; Fri, 25 Feb 2000 16:19:00 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA128142; Fri, 25 Feb 2000 19:21:55 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id TAA159354; Fri, 25 Feb 2000 19:22:50 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256891.000211E5 ; Fri, 25 Feb 2000 19:22:36 -0500
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 19:22:27 -0500
Subject: RE: Straw Poll: SerialNumber definition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     There is one point about Bengt's method which I am slightly confused
by.  Let us suppose that the normal method of putting a unique identifier
for a user into a certificate is by creating a subject alternate name with
a DN consisting of the DN of an assigning authority (most often a country,
an organization, or an organizational unit) followed by a serial number
alone in an RDN.  Does this mean that all DN's in alternate names are to be
interpreted as unique user identifiers, or only all those DN's in alternate
names whose lowest-order RDN consists solely of a serial number?  If the
latter intepretation is accepted, relatively few existing certificates
should be broken.

          Tom Gindin




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04106 for <[e-mail]>; Fri, 25 Feb 2000 14:50:50 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA13888; Fri, 25 Feb 2000 17:54:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080bb4dc836c2980@[171.78.30.107]>
In-Reply-To: <01BF7EED.69EC8380@HYDRA>
References: <01BF7EED.69EC8380@HYDRA>
Date: Fri, 25 Feb 2000 17:53:08 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Cc: "[e-mail]" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1260603158==_ma============"

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

Anders,

>You are free to continue to outlaw DN interpretation support schemes 
>(should include the latest
>suggestions by Stefan and David Kemp) in the same way as dnQualifier 
>in spite of the fact that
>both belong to current practice and work just fine.

Irrespective of the technical issues we are discussing, there seems 
to be some confusion about the purpose of the IETF standards process, 
and of this WG's charter.

It is NOT the goal of this WG to produce standards primarily based on 
current practice.  If that were the case, we would not have 
depricated the use of the Common Name as a means of expressing an RFC 
822 name or a DNS name.  There is considerable common practice here, 
but its inappropriate and thus 2459 strongly encourages use of the 
appropriate name forms and discourages misuse of the DN name form in 
this fashion. So, I think that we have established the flavor of what 
PKIX tries to do in this regard.

The charter of PKIX stated that we were profiling X.509 standards for 
use in the Internet, extending such standards as needed to meet 
Internet needs.  Sometimes we diverge from X.509, when we think it is 
absolutely necessary, but we usually work with the X.509 folks to 
achieve compatible solutions.  The proposed change to the definition 
of serialNumber is such an example, and, in the recent past, the 
change to the basicConstraints extension.  So, we do take issues at 
times with what X.509 does, and we work to resolve such problems, but 
we do not do so lightly.

The issue that triggered this expending debate was the observation 
that an ID number assigned as part of a DN used in a QC might, in 
many instances, uniquely identify the subject. Moreover, an RP would 
like to take advantage of this feature to compare two QCs issued with 
differing DNs, but by the same CA, to determine if the same entity 
was represented by them, despite differences in the DN.  I can 
appreciate the desire to be able to make such a comparison, but I 
also note that this comparison approach clearly assumes knowledge 
outside of the DN semantics.

What we have here is a desire to have one's cake and eat it too :-). 
You want to make use of the DN syntax because of the ability of 
existing software to parse DNs, but the semantics of what you want to 
express is not really a DN. In other instances we have defined new 
objects to represent other name types, but here, since name would 
make use of the same attributes, it seems less critical to define a 
new object under the GeneralName  structure. The challenge is to 
consider way to resolve this issue, without breaking the existing 
semantics of DNs and while minimizing the need to create new 
software. Fortunately, i think we have a porposal that does that, as 
explained below.

Tom Gindin posed a good set of questions that are related to the 
issue I described above, but also are somewhat independent. I think 
the redefinition of serialNumber addresses the fundamental concern he 
raised.  However, this redefinition, although it allows a unique, 
national ID to be represented, does not change the semantics of a DN 
in support of the comparison goal described above.  To know that a 
serialNumber attribute has the property of uniquely identifying a 
subjetc, all but itself, one has to communicate this in some fashion 
to software operating for RPs.

Dave Kemp provided some good explanatory diagrams in his message this 
week, and suggested a delimiter approach to breaking the DN into a 
prefix that uniquely identifies a subject, vs. a suffix that is just 
for display purposes. This is an example of a much more powerful 
mechanism, that goes beyond the original problem and tries to provide 
a means of generally expressing what parts of a DN are critical for 
uniqueness, vs. what parts are just for display to a user. Peter 
Sylvester suggested the same sort of marker. I'm not comfortable with 
this approach because it represents a fundamental change to the 
semantics of a DN, and others are not happy with it since it 
introduces a new attribute, which could cause backward compatibility 
problems.

Stefan suggested a bit string approach to specifying which attributes 
contribute to the unique part of the DN.  This approach avoids the 
for a new attribute, but suffers from the fact that some of these 
attributes can be replicated in a DN, so that the bit string may not 
be able to express the exact attribute subset unless some constraints 
are imposed on the DN schema. Denis's refinement of this approach 
depends on an old RFC that recommends schema constraints for the DNs. 
I tried to do this sort of thing several years earlier in RFC 1422, 
and was suitably chastised then. I don't think it's any more viable 
now.

Bengt Ohlsson suggested another approach to the general problem, 
putting the "unique" DN in the Subject Alt Name extension, as a 
directoryName. This avoids the need for a new extension, the need to 
create a new attribute,  or the need to impose schema constraints. 
However, the example he provides does not exactly match the scenarios 
we have been describing; he said "if the serialNumber attribute is 
unique by itself, then the SubjectAltName entry will only contain the 
serialNumber."  This example would require that the serialNumber be 
globally unique, not just unique per country.  The QC examples we 
have discussed don't involve globally unique ID numbers, so the 
example probably needs to be modified a bit to represent the 
scenarios we have been discussing. This is a valid approach to the 
issue, so long as the SubjectAltNames are real DNs.

Antonio Lioy seconded this approach and gave examples, but here I am 
a bit confused. Antonio spoke of using a distinct OID for each new 
name he inserted; "Each subjectAltName is distinguished by a unique 
OID and hence each application can look for the one that it is able 
to deal with."   Is the OID for an attribute in a directoryName, or 
is it a new GeneralName name type?  The examples provided don;'t 
sounds like DNs: "we use it to insert our unique University ID but a 
second extension could be added for standard Italian national 
personal code, or for the case where the same individual belongs to 
two different organizations." If one creates new attribute types and 
uses them as stand-alone, single attribute DNs, this does not address 
the backward compatibility concerns raised earlier, and these names 
are probably not really DNs, e.g., without other attributes as a 
prefix, they are not likely to be suitable names in the DIT.

I'm comfortable with the approach Bengt proposed, assuming that the 
SubjectAltNames are real DNs, as I explained above. This seems to 
address the original problem, without introducing a new attribute, 
new extension, etc.
I would avoid constructs that put an arbitrary set of attributes into 
this extension, though, if calling the result a DN would be a 
misnomer. Also, I'm not a big fan of putting in multiple 
SubjectAltNames. Doing so causes added complexity in applying the 
NameConstraints extension and it imposes burdens on CAs to verify 
identity information from a wider range of name spaces.  However, for 
purposes of solving the problem that started this thread, I think we 
have a solution.

Finally, Anders, this does nothing to address your more recent desire 
to impose the concept of a naming domain on DNs.  Since DNs exist in 
the context of a DIT, which establishes naming domains via hierarchic 
refinement (the same way the DNS does), I suspect that what you are 
asking for here is not consistent with the use of a DN anyway.  Maybe 
we're back at the "have your cake and eat it too" stage for this 
issue.

Steve

--============_-1260603158==_ma============
Content-Type: text/enriched; charset="us-ascii"

Anders,


<excerpt>You are free to continue to outlaw DN interpretation support
schemes (should include the latest

suggestions by Stefan and David Kemp) in the same way as dnQualifier in
spite of the fact that

both belong to current practice and work just fine.

</excerpt>

<bigger>Irrespective of the technical issues we are discussing, there
seems to be some confusion about the purpose of the IETF standards
process, and of this WG's charter.


It is NOT the goal of this WG to produce standards primarily based on
current practice.  If that were the case, we would not have depricated
the use of the Common Name as a means of expressing an RFC 822 name or
a DNS name.  There is considerable common practice here, but its
inappropriate and thus 2459 strongly encourages use of the appropriate
name forms and discourages misuse of the DN name form in this fashion.
So, I think that we have established the flavor of what PKIX tries to
do in this regard.


The charter of PKIX stated that we were profiling X.509 standards for
use in the Internet, extending such standards as needed to meet
Internet needs.  Sometimes we diverge from X.509, when we think it is
absolutely necessary, but we usually work with the X.509 folks to 
achieve compatible solutions.  The proposed change to the definition of
serialNumber is such an example, and, in the recent past, the change to
the basicConstraints extension.  So, we do take issues at times with
what X.509 does, and we work to resolve such problems, but we do not do
so lightly.


The issue that triggered this expending debate was the observation that
an ID number assigned as part of a DN used in a QC might, in many
instances, uniquely identify the subject. Moreover, an RP would like to
take advantage of this feature to compare two QCs issued with differing
DNs, but by the same CA, to determine if the same entity was
represented by them, despite differences in the DN.  I can appreciate
the desire to be able to make such a comparison, but I also note that
this comparison approach clearly assumes knowledge outside of the DN
semantics.  


What we have here is a desire to have one's cake and eat it too :-). 
You want to make use of the DN syntax because of the ability of
existing software to parse DNs, but the semantics of what you want to
express is not really a DN. In other instances we have defined new
objects to represent other name types, but here, since name would make
use of the same attributes, it seems less critical to define a new
object under the GeneralName  structure. The challenge is to consider
way to resolve this issue, without breaking the existing semantics of
DNs and while minimizing the need to create new software. Fortunately,
i think we have a porposal that does that, as explained below.


Tom Gindin posed a good set of questions that are related to the issue
I described above, but also are somewhat independent. I think the
redefinition of serialNumber addresses the fundamental concern he
raised.  However, this redefinition, although it allows a unique,
national ID to be represented, does not change the semantics of a DN in
support of the comparison goal described above.  To know that a
serialNumber attribute has the property of uniquely identifying a
subjetc, all but itself, one has to communicate this in some fashion to
software operating for RPs.


Dave Kemp provided some good explanatory diagrams in his message this
week, and suggested a delimiter approach to breaking the DN into a
prefix that uniquely identifies a subject, vs. a suffix that is just
for display purposes. This is an example of a much more powerful
mechanism, that goes beyond the original problem and tries to provide a
means of generally expressing what parts of a DN are critical for
uniqueness, vs. what parts are just for display to a user. Peter
Sylvester suggested the same sort of marker. I'm not comfortable with
this approach because it represents a fundamental change to the
semantics of a DN, and others are not happy with it since it introduces
a new attribute, which could cause backward compatibility problems.


Stefan suggested a bit string approach to specifying which attributes
contribute to the unique part of the DN.  This approach avoids the for
a new attribute, but suffers from the fact that some of these
attributes can be replicated in a DN, so that the bit string may not be
able to express the exact attribute subset unless some constraints are
imposed on the DN schema. Denis's refinement of this approach depends
on an old RFC that recommends schema constraints for the DNs.  I tried
to do this sort of thing several years earlier in RFC 1422, and was
suitably chastised then. I don't think it's any more viable now.


Bengt Ohlsson suggested another approach to the general problem,
putting the "unique" DN in the Subject Alt Name extension, as a
directoryName. This avoids the need for a new extension, the need to
create a new attribute,  or the need to impose schema constraints.
However, the example he provides does not exactly match the scenarios
we have been describing; he said "</bigger>if the serialNumber
attribute is unique by itself, then the SubjectAltName entry will only
contain the serialNumber."  <bigger>This example would require that the
serialNumber be globally unique, not just unique per country.  The QC
examples we have discussed don't involve globally unique ID numbers, so
the example probably needs to be modified a bit to represent the
scenarios we have been discussing. This is a valid approach to the
issue, so long as the SubjectAltNames are real DNs.


Antonio Lioy seconded this approach and gave examples, but here I am a
bit confused. Antonio spoke of using a distinct OID for each new name
he inserted; "</bigger>Each subjectAltName is distinguished by a unique
OID and hence each application can look for the one that it is able to
deal with.<bigger>"   Is the OID for an attribute in a directoryName,
or is it a new GeneralName name type?  The examples provided don;'t
sounds like DNs: "</bigger>we use it to insert our unique University ID
but a second extension could be added for standard Italian national
personal code, or for the case where the same individual belongs to two
different organizations.<bigger>" If one creates new attribute types
and uses them as stand-alone, single attribute DNs, this does not
address the backward compatibility concerns raised earlier, and these
names are probably not really DNs, e.g., without other attributes as a
prefix, they are not likely to be suitable names in the DIT.  


I'm comfortable with the approach Bengt proposed, assuming that the
SubjectAltNames are real DNs, as I explained above. This seems to
address the original problem, without introducing a new attribute, new
extension, etc.

I would avoid constructs that put an arbitrary set of attributes into
this extension, though, if calling the result a DN would be a misnomer.
Also, I'm not a big fan of putting in multiple SubjectAltNames. Doing
so causes added complexity in applying the NameConstraints extension
and it imposes burdens on CAs to verify identity information from a
wider range of name spaces.  However, for purposes of solving the
problem that started this thread, I think we have a solution.


Finally, Anders, this does nothing to address your more recent desire
to impose the concept of a naming domain on DNs.  Since DNs exist in
the context of a DIT, which establishes naming domains via hierarchic
refinement (the same way the DNS does), I suspect that what you are
asking for here is not consistent with the use of a DN anyway.  Maybe
we're back at the "have your cake and eat it too" stage for this
issue.


Steve
</bigger>

--============_-1260603158==_ma============--


Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03278 for <[e-mail]>; Fri, 25 Feb 2000 14:04:05 -0800 (PST)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <1JW6NVL7>; Fri, 25 Feb 2000 17:07:58 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: Cert Path Validation Bug in pkix-new-part1-00 
Date: Fri, 25 Feb 2000 17:07:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

There is a bug in the certification path validation Wrap-up procedures
section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
<draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
public key is used to verify an end-entity cert containing an RSA public
key, then the current Wrap-up procedure does not properly set the
working_public_key_parameters variable to NULL.  With the current procedure,
the working_public_key_parameters is still set to the issuer's DSS algorithm
parameters.  Recommend the following change to section 6.1.5:

OLD:  (d) 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.

NEW:  (d) 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, 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.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 




Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02800 for <[e-mail]>; Fri, 25 Feb 2000 13:44:31 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA174744; Fri, 25 Feb 2000 16:47:30 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA239476; Fri, 25 Feb 2000 16:48:45 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256890.0077C933 ; Fri, 25 Feb 2000 16:48:22 -0500
X-Lotus-FromDomain: IBMUS
To: "Hesse, Johan" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 16:48:10 -0500
Subject: Re: AW: German Law and OCSP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     There is also a set of technical rules associated with that
presidential decree at the link
http://www.aipa.it/attivita[2/protocollo[13/normprot[1/regole428.asp.
Please note that the link contains left square brackets in file names, not
parentheses.

          Tom Gindin




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA29990 for <[e-mail]>; Fri, 25 Feb 2000 10:23:38 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 25 Feb 2000 11:27:20 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 25 Feb 2000 11:27:06 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>
Subject: Re: What if the CRL distribution points for a CA change?
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA29992

Some clarification seems to be in order....

The idea of having multiple distribution points in a certificate seems very reasonable in our context at Novell.  For our PKI, it is quite convenient to name at least two distribution points:  one which is an X.500 name and one which is an LDAP address.  Since our PKI is integrated with our directory (NDS), it is natural for us to prefer retrieving the CRLs directly from NDS rather than using LDAP.  But, because there are applications out there that are not NDS-aware, we'd like to include other distribution points which can be accessed from outside of the company via HTTP or LDAP.  

As for changing the distribution points, there are a couple of scenarios that I can envision where they would be changed.  How true-to-life these scenarios are is something that I'm hoping to discover.

1.  The one externally-available distribution point (say it is LDAP) currently listed in the certificates just doesn't have enough bandwidth to accommodate all the queries.  Or, the software package that the CEO of the company is using can't use LDAP to get CRLs ¯ it must use HTTP.  The CA Administrator is forced to add additional distribution points to accommodate other protocols and/or unexpected traffic.

2.  One of the distribution points is being phased out (for whatever reason).  Maybe the company no longer wants to support LDAP access to its directory.  Or maybe the company has made an agreement with another organization to post its CRLs on their high-volume servers.

3.  The CA in question issues a million certificates a year and expects that half of all of those certificates will be revoked.  The CRLs for that CA would become quite large, and, after some calculations, the CA Administrator decides that CRLs of that size are unacceptable.  He therefore decides to change the CRL distribution points every year.  So, basically, for those certificates issued in the first year, their CRLs would be found on distribution points A and B.  For those certificates issued in the second year, their CRLs would be found on distribution points C and D.  If my option (b) were used here, then the CRLs found on A, B, C, and D would contain a maximum of 1 million certificates certificates each in the worst case where all the certificates were revoked (CRL on A = CRL on B; CRL on C = CRL on D; CRL on A != CRL on C).  [If option (a) were used here, the CA Administrator would have a nasty surprise in that the CRLs on A, B, C, and D would be exactly the same and contain 2 million certificates in the worst case scenario.]


Are these scenarios something that you would find in the real world?  If so, then is it acceptable to make the CRLs on all distribution points ever specified the same?  Or, should they contain only the minimum number of certificates?


Tammy Green
[e-mail] 
Software Engineer
Novell, Inc.

>>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
Don't do that?

I.e., :

1.  Don't issue certificates containing multiple distribution points.

2.  If issuing certificates with multiple distribution points is absolutely necessary (for some reason I can't quite fathom), don't change the distribution points unless you are prepared to implement option b.

If we restrict the type of distribution points to LDAP queries, wouldn't it be possible to remap the DNS name of the server as might be required for load balancing, leaving the LDAP query itself unmodified?  Doesn't this eliminate the entire problem?

Bob



>>> Tammy Green 02/24/00 08:58PM >>>
Say a CA begins minting certificates with distribution points A, B, and C in the certificates.  It issues 10 certificates.  Then, at time t1, it changes the distribution points to A, D, and E and issues 10 more certificates.

Now say that at time t2 certificate 1 was revoked as well as certificate 11.  What should the CA do when it comes time to issue the CRL?  [Assume here that the CA is only issuing a basic CRL that is not subdivided by reason codes, etc.]  It appears that there are two options.

(a)  Issue one CRL containing entries for certificate 1 and 11.  Post that CRL to distribution points A, B, C, D, and E.

(b)  Issue one CRL containing entries for certificate 1 and 11 and post that CRL to distribution point A.  Then issue another CRL containing an entry for only certificate 1 and post that CRL to distribution points B and C.  Finally issue yet another CRL containing an entry for only certificate 10 and post that CRL to distribution points D and E.

Option a has the disadvantage of causing needless bloat to the CRLs posted on distribution points B, C, D, and E:  no one will look for revocation information about certificate 1 on distribution point D or E, and, likewise, no one will look for revocation information about certificate 11 on distribution point B or C.  Option a does have the advantage of being far easier to implement, however.

Option b has the disadvantage of being much more complex.  And, each time the set of distribution points is modified, the complexity increases as does the time required to generate all of the CRLs which are required.  However, the advantage is that the CRLs that are posted to the distribution points contain only useful information.

Are there other solutions?  Preferences?  Implementations?  Guidelines?


Tammy Green
[e-mail] 
Software Engineer
Novell, Inc.




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28770 for <[e-mail]>; Fri, 25 Feb 2000 08:53:21 -0800 (PST)
Received: from bull.net (itinerant4.frpq.bull.fr [129.184.8.52]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA28784; Fri, 25 Feb 2000 17:57:48 +0100
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 17:57:30 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Herfert <[e-mail]>
CC: [e-mail]
Subject: Re: German Law and OCSP
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael,

Thank for attempting to answer to the question. However, the right
explanation is not contained in this E-mail where it is said: "user
certificates must remain valid if a CA looses the license", but in
the other E-mail sent to Hans Nilsson where it is said:

"The german law requires that user certificates must be valid, even
if the CA key has been corrupted."

This sentence does not appear in the extracts you provide below:

1) The first sentence of §13 (5) does not address the case of CA key
compromise.

2) The second sentence of §13 (5) orders invalidation of
certificates which is in contradiction with maintaining the validity
of certificates, even if the CA key has been corrupted.

3) The sentence of §8(3) talks about invalidation, not maintaining
the validity of the certificate.

The fact that by §13(5) user certificates must remain valid if a CA
looses the license, does not mean that the CA key is compromised. A
CA may loose its license without any key compromission.

The idea is nevertheless to consider the way to handle the case of
CA key compromission. 

The basic question is whether there is a need to modify RFC 2459 to
handle CA key compromission. If there is such a need, this cannot
interpreted from this text.

Denis


> Hello Denis and all,
> 
> Denis Pinkas wrote:
> > Besides the wording, the question was to understand the rational of
> > the model. The question is still pending ...
> 
> The standard X.509 model does not satisfy the requierements of the german
> law. So there was a need for a new model. The important paragraphs are:
> 
> §13(5): "The validity of the certificates issued by a certification
>          authority shall remain unaffected by the withdrawal or
>          revocation of a licence. The competent authority may order the
>          invalidation of certificates when facts warrant the assumption
>          that certificates have been forged or are not adequately
>          protected against forgery or when technical components
>          used for the signature keys reveal security flaws enabling
>          digital signatures to be forged or signed data to be
>          manipulated without detection."
> 
> §8(3):  "The competent authority shall invalidate certificates which it has
>          issued according to §4(5) when a certification authority
>          ceases operation or its licence is withdrawn or revoked."
> 
> Assume a CA looses its license, for example because it has lost its money.
> According to §8(3) the competent authority (= the german root CA)
> must revoke the certificate.
> 
> By §13(5) user certificates must remain valid if a CA looses the license.
> 
> So we have a revoked CA certificate and valid user certificates.
> This case can not be handled by the standard X.509 model.
> 
> ---
> 
> The SigG model is an easy and effective model.
> Assume a two level hierarchy:
>         root CA
>         CA
>         users
> 
> 1. Now Alice wants to verify 10000 digital signatures
>    with respect to the standard model.
>    She decides that she needs online verification of certificates.
>    For the first signature she must ask her online service three times:
>      to verify the user certificate
>      to verify the CA certificate
>      to verify the root certificate
>    So for 10000 verifications she needs 30000 requests.
> 
> 2. On the other side, Bob verifies the same amount of signatures
>    by the SigG model.
>    He first verifies the CA and the root CA certificates.
>    He can store the results and reuse them in the future.
>    So for 10000 verifications Bob needs 10002 requests.
> 
> ---
> 
> A standard X.509 directory service may be joined with the german signature law.
> Alice ask this service for the certificate of Bob.
> The service answers by sending Bob's certificate
> (if Bob has allowed this).
> The certificate is signed by the CA, like always,
> but it has no extra signature.
> The meaning of the answer is:
>   Alice, this is Bob's certificate. It may be valid
>   or not. If you want to know the exact status,
>   ask the validation service.
> 
> If we replace the words "validation service" by "OCSP"
> then this is exact the meaning we have in the standard model.
> 
> Greetings,
> Michael
> 
> ---
> 
> Michael Herfert
> GMD - German National Research Center for Information Technology
> Darmstadt
> Germany


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27688 for <[e-mail]>; Fri, 25 Feb 2000 07:36:56 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLXXNS>; Fri, 25 Feb 2000 07:31:59 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: [e-mail]
Subject: RE: German Law and OCSP
Date: Fri, 25 Feb 2000 07:31:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA27689

Hi Michael,
    - The requirements you have specified could be met by using
standard OCSP and requiring the VA to send over the full cert
hash in the response.
    - If a CA cert signing key has been compromised, I would
treat everything issued by the CA as suspect - you would open
yourself up to too many attacks - it isn't worth it to try and
save the certificates that were legitimately issued.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Michael Herfert [mailto:[e-mail]]
> Sent: Friday, February 25, 2000 7:14 AM
> To: Denis Pinkas; [e-mail]
> Subject: Re: German Law and OCSP
> 
> 
> Hello Denis and all,
> 
> Denis Pinkas wrote:
> > Besides the wording, the question was to understand the rational of
> > the model. The question is still pending ...
> 
> The standard X.509 model does not satisfy the requierements 
> of the german 
> law. So there was a need for a new model. The important 
> paragraphs are:
> 
> 
> §13(5):	"The validity of the certificates issued by a 
> certification 
>          authority shall remain unaffected by the withdrawal or 
> 	 revocation of a licence. The competent authority may order the
>      	 invalidation of certificates when facts warrant the assumption 
> 	 that certificates have been forged or are not adequately 
> 	 protected against forgery or when technical components
>      	 used for the signature keys reveal security flaws enabling 
> 	 digital signatures to be forged or signed data to be 
> 	 manipulated without detection." 
> 
> §8(3):	"The competent authority shall invalidate 
> certificates which it has 
>   	 issued according to §4(5) when a certification authority 
>       	 ceases operation or its licence is withdrawn 
> or revoked."
> 
> 
> Assume a CA looses its license, for example because it has 
> lost its money.
> According to §8(3) the competent authority (= the german root CA) 
> must revoke the certificate. 
> 
> By §13(5) user certificates must remain valid if a CA looses 
> the license.
> 
> So we have a revoked CA certificate and valid user certificates.
> This case can not be handled by the standard X.509 model.
> 
> ---
> 
> The SigG model is an easy and effective model.
> Assume a two level hierarchy:  
> 	root CA
> 	CA
> 	users
> 
> 1. Now Alice wants to verify 10000 digital signatures 
>    with respect to the standard model.
>    She decides that she needs online verification of certificates.
>    For the first signature she must ask her online service 
> three times:
>      to verify the user certificate
>      to verify the CA certificate
>      to verify the root certificate
>    So for 10000 verifications she needs 30000 requests.
> 
> 2. On the other side, Bob verifies the same amount of signatures
>    by the SigG model.
>    He first verifies the CA and the root CA certificates.
>    He can store the results and reuse them in the future.
>    So for 10000 verifications Bob needs 10002 requests.
> 
> ---
> 
> A standard X.509 directory service may be joined with the 
> german signature law.
> Alice ask this service for the certificate of Bob.
> The service answers by sending Bob's certificate 
> (if Bob has allowed this).
> The certificate is signed by the CA, like always,
> but it has no extra signature.
> The meaning of the answer is: 
>   Alice, this is Bob's certificate. It may be valid
>   or not. If you want to know the exact status,
>   ask the validation service.
> 
> If we replace the words "validation service" by "OCSP" 
> then this is exact the meaning we have in the standard model.
> 
> Greetings,
> Michael
> 
> ---
> 
> Michael Herfert
> GMD - German National Research Center for Information Technology
> Darmstadt
> Germany
> 


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27049 for <[e-mail]>; Fri, 25 Feb 2000 07:08:22 -0800 (PST)
Received: from gmd.de (pc-jinni [141.12.33.84]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id QAA20982; Fri, 25 Feb 2000 16:11:13 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 16:14:15 +0100
From: Michael Herfert <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>, [e-mail]
Subject: Re: German Law and OCSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello Denis and all,

Denis Pinkas wrote:
> Besides the wording, the question was to understand the rational of
> the model. The question is still pending ...

The standard X.509 model does not satisfy the requierements of the german 
law. So there was a need for a new model. The important paragraphs are:


§13(5):	"The validity of the certificates issued by a certification 
         authority shall remain unaffected by the withdrawal or 
	 revocation of a licence. The competent authority may order the
     	 invalidation of certificates when facts warrant the assumption 
	 that certificates have been forged or are not adequately 
	 protected against forgery or when technical components
     	 used for the signature keys reveal security flaws enabling 
	 digital signatures to be forged or signed data to be 
	 manipulated without detection." 

§8(3):	"The competent authority shall invalidate certificates which it has 
  	 issued according to §4(5) when a certification authority 
      	 ceases operation or its licence is withdrawn or revoked."


Assume a CA looses its license, for example because it has lost its money.
According to §8(3) the competent authority (= the german root CA) 
must revoke the certificate. 

By §13(5) user certificates must remain valid if a CA looses the license.

So we have a revoked CA certificate and valid user certificates.
This case can not be handled by the standard X.509 model.

---

The SigG model is an easy and effective model.
Assume a two level hierarchy:  
	root CA
	CA
	users

1. Now Alice wants to verify 10000 digital signatures 
   with respect to the standard model.
   She decides that she needs online verification of certificates.
   For the first signature she must ask her online service three times:
     to verify the user certificate
     to verify the CA certificate
     to verify the root certificate
   So for 10000 verifications she needs 30000 requests.

2. On the other side, Bob verifies the same amount of signatures
   by the SigG model.
   He first verifies the CA and the root CA certificates.
   He can store the results and reuse them in the future.
   So for 10000 verifications Bob needs 10002 requests.

---

A standard X.509 directory service may be joined with the german signature law.
Alice ask this service for the certificate of Bob.
The service answers by sending Bob's certificate 
(if Bob has allowed this).
The certificate is signed by the CA, like always,
but it has no extra signature.
The meaning of the answer is: 
  Alice, this is Bob's certificate. It may be valid
  or not. If you want to know the exact status,
  ask the validation service.

If we replace the words "validation service" by "OCSP" 
then this is exact the meaning we have in the standard model.

Greetings,
Michael

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26813 for <[e-mail]>; Fri, 25 Feb 2000 07:04:47 -0800 (PST)
Received: from gmd.de (pc-jinni [141.12.33.84]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id QAA20633; Fri, 25 Feb 2000 16:07:54 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 16:10:56 +0100
From: Michael Herfert <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Hans Nilsson <[e-mail]>
CC: "'Ambarish Malpani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Hans Nilsson wrote:
> (For non-German speakers: "Good" means that the certificate is issued by the
> CA, known in the Directory and not revoked)
> 
> This is quite a different interpretation of "good" from RFC 2560, where
> "good" not necessarily means that the certificate has been issued!!!

there are two important differences between standard OCSP and SigG OCSP:

1. The meaning of "good":
   I think Hans is right in this point.

2. The single request extension certHash:
   The german law requires that user certificates must 
   be valid, even if the CA key has been corrupted.
   The extensions certHash contains the hash value of the certificate 
   being asked. It is a MUST in every request. 
   Without this value the service would not work 
   according to the law because the identification of a certificate by 
   (issuerNameHash, issuerKeyHash, serialNumber)
   is only a valid reference if the CA cert signing key is okay.
   Assume Alice has the serial number 5.
   In a desaster case where the CA cert signing key has been broken,
   an attacker may generate a certificate for Bob which has the 
   serial number 5, too. 
   In the same matter he may generate many faked certificates 
   that share a serial number with a correct certificate.
   

Michael 

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26589 for <[e-mail]>; Fri, 25 Feb 2000 07:02:21 -0800 (PST)
Received: from gmd.de (pc-jinni [141.12.33.84]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id QAA20438; Fri, 25 Feb 2000 16:06:02 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2000 16:09:04 +0100
From: Michael Herfert <[e-mail]>
X-Mailer: Mozilla 4.7 [de] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and German Law
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hallo,

Stefan Kelm wrote:
> If someone
> doesn't want your certificate to be validated (e.g., because you digitally
> signed an order to buy one million new shares of that interesting company
> and the attacker doesn't like that) he shuts down the directory server
> for a while.

Consider the X.509 standard model:
If the verifier receives a high value transaction 
he asks his standard OCSP service in order to 
be sure that the certificate ist not revoked.
This standard service may be attacked in the same
was as in the SigG case.
So there is no difference with respect to this attack.

Michael 

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany


Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25300 for <[e-mail]>; Fri, 25 Feb 2000 06:03:25 -0800 (PST)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA03179; Fri, 25 Feb 2000 15:06:27 +0100 (MET)
Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA11844; Fri, 25 Feb 2000 15:07:20 +0100 (MET)
Received: by MCHH201E with Internet Mail Service (5.5.2448.0) id <18JZVB8G>; Fri, 25 Feb 2000 15:07:58 +0100
Message-ID: <339813E976DDD31195660008C71EEE34061FF3@MCHH227E>
From: Fantou Patrick <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], Tammy Green <[e-mail]>
Cc: Fantou Patrick <[e-mail]>
Subject: AW: What if the CRL distribution points for a CA change?
Date: Fri, 25 Feb 2000 15:07:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA25301

Hi Bob,

Can you please tell me what you mean with "LDAP forms of CRL distribution
points" ?
Thanks
Patrick
--
----------------------------------------------------------------------------
Patrick Fantou			Tel : [phone]	
Siemens AG			Fax: [phone]
Trusted Networks and Applications
ICN ISA TNA 4
Otto-Hahn-Ring 6, D.81739-Munich, Germany
e-mail : [e-mail]
----------------------------------------------------------------------------
-

> -----Ursprüngliche Nachricht-----
> Von:	Bob Jueneman [SMTP:[e-mail]]
> Gesendet am:	Freitag, 25. Februar 2000 06:50
> An:	[e-mail]; [e-mail]; Tammy Green
> Betreff:	Re: What if the CRL distribution points for a CA change?
> 
> Serves me right for not paying adequate attention to the cc list.  I
> thought I was responding to an internal Novell discussion, and did not
> intend to post such a  flip response to this list, nor to necessarily
> suggest that only LDAP forms of CRL distribution points should be used.
> 
> In the more general context, I think Tammy's points are worth discussing.
> 
> Bob
> 
> >>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
> Don't do that?
> 
> I.e., :
> 
> 1.  Don't issue certificates containing multiple distribution points.
> 
> 2.  If issuing certificates with multiple distribution points is
> absolutely necessary (for some reason I can't quite fathom), don't change
> the distribution points unless you are prepared to implement option b.
> 
> If we restrict the type of distribution points to LDAP queries, wouldn't
> it be possible to remap the DNS name of the server as might be required
> for load balancing, leaving the LDAP query itself unmodified?  Doesn't
> this eliminate the entire problem?
> 
> Bob
> 
> 
> 
> >>> Tammy Green 02/24/00 08:58PM >>>
> Say a CA begins minting certificates with distribution points A, B, and C
> in the certificates.  It issues 10 certificates.  Then, at time t1, it
> changes the distribution points to A, D, and E and issues 10 more
> certificates.
> 
> Now say that at time t2 certificate 1 was revoked as well as certificate
> 11.  What should the CA do when it comes time to issue the CRL?  [Assume
> here that the CA is only issuing a basic CRL that is not subdivided by
> reason codes, etc.]  It appears that there are two options.
> 
> (a)  Issue one CRL containing entries for certificate 1 and 11.  Post that
> CRL to distribution points A, B, C, D, and E.
> 
> (b)  Issue one CRL containing entries for certificate 1 and 11 and post
> that CRL to distribution point A.  Then issue another CRL containing an
> entry for only certificate 1 and post that CRL to distribution points B
> and C.  Finally issue yet another CRL containing an entry for only
> certificate 10 and post that CRL to distribution points D and E.
> 
> Option a has the disadvantage of causing needless bloat to the CRLs posted
> on distribution points B, C, D, and E:  no one will look for revocation
> information about certificate 1 on distribution point D or E, and,
> likewise, no one will look for revocation information about certificate 11
> on distribution point B or C.  Option a does have the advantage of being
> far easier to implement, however.
> 
> Option b has the disadvantage of being much more complex.  And, each time
> the set of distribution points is modified, the complexity increases as
> does the time required to generate all of the CRLs which are required.
> However, the advantage is that the CRLs that are posted to the
> distribution points contain only useful information.
> 
> Are there other solutions?  Preferences?  Implementations?  Guidelines?
> 
> 
> Tammy Green
> [e-mail] 
> Software Engineer
> Novell, Inc.
> 


Received: from mail-int.cubis.de (maildt.cubis.de [212.185.174.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22130 for <[e-mail]>; Fri, 25 Feb 2000 03:37:07 -0800 (PST)
Received: from ex-mail.cubis.de (ex-mail.cubis.de [10.31.4.65]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id MAA28998; Fri, 25 Feb 2000 12:41:53 +0100 (MET)
Received: by ex-mail.cubis.de with Internet Mail Service (5.5.2650.21) id <1PRND60Y>; Fri, 25 Feb 2000 12:39:46 +0100
Message-ID: <[e-mail]>
From: "Hesse, Johan" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: AW: OCSP and German Law
Date: Fri, 25 Feb 2000 12:38:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7F85.03A72F00"

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

------_=_NextPart_001_01BF7F85.03A72F00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> -----Urspr=FCngliche Nachricht-----
> Von:	Stefan Kelm [SMTP:[e-mail]]
> Gesendet am:	Freitag, 25. Februar 2000 10:40
> An:	[e-mail]
> Betreff:	Re: OCSP and German Law
>=20
> Johan,
>=20
> > I agree to Stefan, I bet a box of beer that the "validity model" in =
the
> > German Law won't change.
>=20
> According to the (still internal) drafts of the new law it won't =
change at
> all.
>=20
> > The advantage is more or less of legal and/or organizational =
nature. If
> the
> > CA signs a certificate, the PSE (e.g. your smart card with your
> *private*
> > key) has to be delivered in a secure way to the owner.
> >
> > In technical terms the certificate is almost valid (but not in =
legal
> terms).
> > But the PSE hasn't handed out to the owner yet, - with all =
possibilities
> of
> > abuse (I know there are ways to handle it in another way). But if =
you
> wait
> > until the owner proofs that he received the PSE, to say the =
certificate
> is
> > valid you avoid this insecure time gap. The validation is =
manifested by
> > publishing the certificate.
> >
> > So I hope you see the rational of this validity model.
>=20
> I think this is pretty plausible. However, using this model the =
directory
> is much more burdened with security issues than usual. =
Denial-of-service
> attacks against the directory become much more crucial, IMHO. If =
someone
> doesn't want your certificate to be validated (e.g., because you =
digitally
> signed an order to buy one million new shares of that interesting =
company
> and the attacker doesn't like that) he shuts down the directory =
server
> for a while.
>=20
>=20
	[Hesse, Johan]  Yes, - that's the point. But I didn't say that the
model was the only one or rather the best.
	But the denial of service attacks seems to be independent from this
model (?).

	For contract partner it's of particular importance that they can
check the status of the certificates within some minutes (see your =
example
of the financial transaction). So the DIR has to be available at any =
time.
In practice it will be the weak point.=20

	Cheers, Johan

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : [phone]
> Fax   : [phone]
> mailto:[e-mail]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7F85.03A72F00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>AW: OCSP and German Law</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Urspr=FCngliche =
Nachricht-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Von:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Stefan Kelm [SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Gesendet =
am:&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 FACE=3D"Arial">Freitag, =
25. Februar 2000 10:40</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">An:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Betreff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: OCSP and German Law</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Johan,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I agree to Stefan, I bet a box of =
beer that the &quot;validity model&quot; in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; German Law won't change.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">According to the (still internal) =
drafts of the new law it won't change at all.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The advantage is more or less of =
legal and/or organizational nature. If the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; CA signs a certificate, the PSE =
(e.g. your smart card with your *private*</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; key) has to be delivered in a =
secure way to the owner.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In technical terms the =
certificate is almost valid (but not in legal terms).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; But the PSE hasn't handed out to =
the owner yet, - with all possibilities of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; abuse (I know there are ways to =
handle it in another way). But if you wait</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; until the owner proofs that he =
received the PSE, to say the certificate is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; valid you avoid this insecure =
time gap. The validation is manifested by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; publishing the =
certificate.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; So I hope you see the rational =
of this validity model.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think this is pretty plausible. =
However, using this model the directory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is much more burdened with security =
issues than usual. Denial-of-service</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">attacks against the directory become =
much more crucial, IMHO. If someone</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">doesn't want your certificate to be =
validated (e.g., because you digitally</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signed an order to buy one million =
new shares of that interesting company</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and the attacker doesn't like that) =
he shuts down the directory server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for a while.</FONT>
</P>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Yes, - that's the point. But I didn't say that the =
model was the only one or rather the best.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But the denial of =
service attacks seems to be independent from this model (?).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For contract partner =
it's of particular importance that they can check the status of the =
certificates within some minutes (see your example of the financial =
transaction). So the DIR has to be available at any time. In practice =
it will be the weak point.</FONT> </P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers, =
Johan</FONT></I></B>
</P>
</UL>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7F85.03A72F00--


Received: from mail-int.cubis.de (maildt.cubis.de [212.185.174.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21414 for <[e-mail]>; Fri, 25 Feb 2000 03:22:09 -0800 (PST)
Received: from ex-mail.cubis.de (ex-mail.cubis.de [10.31.4.65]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id MAA27222; Fri, 25 Feb 2000 12:27:16 +0100 (MET)
Received: by ex-mail.cubis.de with Internet Mail Service (5.5.2650.21) id <1PRND68S>; Fri, 25 Feb 2000 12:25:09 +0100
Message-ID: <[e-mail]>
From: "Hesse, Johan" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: AW: German Law and OCSP
Date: Fri, 25 Feb 2000 12:23:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7F82.F8A090B0"

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

------_=_NextPart_001_01BF7F82.F8A090B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> -----Urspr=FCngliche Nachricht-----
> Von:	Paul Halliden [SMTP:[e-mail]]
> Gesendet am:	Donnerstag, 24. Februar 2000 17:53
> An:	'Hesse, Johan'; [e-mail]; [e-mail];
> [e-mail]
> Cc:	[e-mail]
> Betreff:	RE: German Law and OCSP
>=20
> > It seems that there are a lot of confusions regarding some terms=20
> > in the German Law. =20
> Agreed ;)
>=20
> [snip]
>=20
> > I think the confusion springs from legal terms. In the above=20
> > mentioned example the technical term of *valid* for a certificate=20
> > would be the moment of the signing with the signing key.=20
> Technically a certificate is valid from the date and time contained =
in the
> ASN.1 element "notBefore" in the "Validity" sequence of the X.509
> structure.
> This may or may not be the time of signing by the CA.  Indeed, it may =
be
> delayed with respect to time of signing to cope with the scenario you
> describe in your later mail.  This is the same as the process known =
as
> "Thro
> dating" used by credit card companies to protect against the risks =
you
> mention.
>=20
	[Hesse, Johan]  O.k. But the element "notBefore" doesn't help in
this scenario. If you don't know how long it exactly takes that the PSE =
is
handed out to the intended end user. May be 2 minutes and the user =
wants to
sign immediately (personal handing out), or 2 weeks (the user is absent =
and
sends the acknowledgement later).

> > The legal term assumes the publishing of the certificate.
> >
> > Another misunderstanding seems to be the role of the CRL in German =
Law.=20
> > Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> > to prove that a cert was not valid at a certain date is to provide
> > a CRL (or a CSL!!!) that includes it." The German Law requires
> > only the *checkability* of the status of a certificate for anybody=20
> > to any time (=A74 SigG).=20
> This is =A75(1) in my (English) copy dated 1 August 1997.  Is there a =
later
> version?  More importantly, it was explained to me that the German =
model
> needed to know if a certificate was valid at the time that the
> corresponding
> signature key was originally used and not at the time the request for
> validation is performed.  This is because one might be checking a =
legal
> document that is tens of years old.  Is that what you mean by "to any
> time"?
>=20
	[Hesse, Johan]  You are right, =A75. I have to learn the Law by heart
again ;-)
> > The interoperability schemes (SigI A5) propose OCSP.=20
> As I understand it, OCSP is designed to tell you status now not =
status at
> some previous date.  If so, is this another issue with German Law and
> OCSP?
>=20
> > The status *suspension* isn't allowed according to the German Law,=20
> > in comparison with Italian law which requires a CRL (Art. 29 par. =
3)
> > and the possibility of suspension (Art. 33).
> Do you have a reasonable English translation of the Italian law - or =
a
> link
> to a translation?
>=20
>=20
	[Hesse, Johan]  Sorry, I have the law only in italian. The details
concerning suspension and CRL as mentioned above can be find in the =
"Decreto
del Presidente del Consiglio dei Ministri, 8 febbraio 1999" under
http://www.aipa.it/servizi[3/normativa[4/leggi[1/regfin.asp  .     =20



	Ciao, Johan


> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : [phone]
> Fax   : [phone]
> mailto:[e-mail]
> **************************************
>=20
>=20
>=20
>=20

------_=_NextPart_001_01BF7F82.F8A090B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>AW: German Law and OCSP</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Urspr=FCngliche =
Nachricht-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Von:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Paul Halliden =
[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Gesendet =
am:&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donnerstag, 24. Februar 2000 17:53</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">An:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Hesse, Johan'; [e-mail]; [e-mail]; =
[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Betreff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: German Law and OCSP</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; It seems that there are a lot of =
confusions regarding some terms </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in the German Law.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Agreed ;)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I think the confusion springs =
from legal terms. In the above </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; mentioned example the technical =
term of *valid* for a certificate </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; would be the moment of the =
signing with the signing key. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technically a certificate is valid =
from the date and time contained in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ASN.1 element &quot;notBefore&quot; =
in the &quot;Validity&quot; sequence of the X.509 structure.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This may or may not be the time of =
signing by the CA.&nbsp; Indeed, it may be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">delayed with respect to time of =
signing to cope with the scenario you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">describe in your later mail.&nbsp; =
This is the same as the process known as &quot;Thro</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dating&quot; used by credit card =
companies to protect against the risks you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mention.</FONT>
</P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> O.k. But the element &quot;notBefore&quot; doesn't help =
in this scenario. If you don't know how long it exactly takes that the =
PSE is handed out to the intended end user. May be 2 minutes and the =
user wants to sign immediately (personal handing out), or 2 weeks (the =
user is absent and sends the acknowledgement later).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The legal term assumes the =
publishing of the certificate.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Another misunderstanding seems =
to be the role of the CRL in German Law. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Antonio Lioy wrote (28.01.2000) =
&quot;... the only legally binding way</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to prove that a cert was not =
valid at a certain date is to provide</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a CRL (or a CSL!!!) that =
includes it.&quot; The German Law requires</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; only the *checkability* of the =
status of a certificate for anybody </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to any time (=A74 SigG). </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This is =A75(1) in my (English) copy =
dated 1 August 1997.&nbsp; Is there a later</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">version?&nbsp; More importantly, it =
was explained to me that the German model</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">needed to know if a certificate was =
valid at the time that the corresponding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signature key was originally used and =
not at the time the request for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">validation is performed.&nbsp; This =
is because one might be checking a legal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">document that is tens of years =
old.&nbsp; Is that what you mean by &quot;to any time&quot;?</FONT>
</P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> You are right, =A75. I have to learn the Law by heart =
again ;-)</FONT><B></B><B><I></I></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The interoperability schemes =
(SigI A5) propose OCSP. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As I understand it, OCSP is designed =
to tell you status now not status at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some previous date.&nbsp; If so, is =
this another issue with German Law and OCSP?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The status *suspension* isn't =
allowed according to the German Law, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in comparison with Italian law =
which requires a CRL (Art. 29 par. 3)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and the possibility of =
suspension (Art. 33).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Do you have a reasonable English =
translation of the Italian law - or a link</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to a translation?</FONT>
</P>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Sorry, I have the law only in italian. The details =
concerning suspension and CRL as mentioned above can be find in the =
&quot;Decreto del Presidente del Consiglio dei Ministri, 8 febbraio =
1999&quot; under<U> <A HREF=3D"http://www.aipa.it/servizi" =
TARGET=3D"_blank">http://www.aipa.it/servizi</A>[3/normativa[4/leggi[1/r=
egfin.asp</U></FONT><U></U><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"> .</FONT></I><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT></B>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"></FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"></FONT></I></B><I></I>&nbsp;<FONT SIZE=3D2 =
FACE=3D"Arial"> </FONT></P>
<BR>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Ciao, =
Johan</FONT></I></B>
</P>
<BR>
</UL>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7F82.F8A090B0--


Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14753 for <[e-mail]>; Fri, 25 Feb 2000 01:38:36 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id KAA12789 for [e-mail]; Fri, 25 Feb 2000 10:40:29 +0100 (MET)
Date: Fri, 25 Feb 2000 10:40:29 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: OCSP and German Law
X-Sun-Charset: US-ASCII
Reply-To: [e-mail]

Johan,

> I agree to Stefan, I bet a box of beer that the "validity model" in the
> German Law won't change.

According to the (still internal) drafts of the new law it won't change at all.

> The advantage is more or less of legal and/or organizational nature. If the
> CA signs a certificate, the PSE (e.g. your smart card with your *private*
> key) has to be delivered in a secure way to the owner.
>
> In technical terms the certificate is almost valid (but not in legal terms).
> But the PSE hasn't handed out to the owner yet, - with all possibilities of
> abuse (I know there are ways to handle it in another way). But if you wait
> until the owner proofs that he received the PSE, to say the certificate is
> valid you avoid this insecure time gap. The validation is manifested by
> publishing the certificate.
>
> So I hope you see the rational of this validity model.

I think this is pretty plausible. However, using this model the directory
is much more burdened with security issues than usual. Denial-of-service
attacks against the directory become much more crucial, IMHO. If someone
doesn't want your certificate to be validated (e.g., because you digitally
signed an order to buy one million new shares of that interesting company
and the attacker doesn't like that) he shuts down the directory server
for a while.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA                                                      <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA12320 for <[e-mail]>; Fri, 25 Feb 2000 00:48:14 -0800 (PST)
Received: from mega (t1o69p85.telia.com [62.20.144.85]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA30954 for <[e-mail]>; Fri, 25 Feb 2000 09:55:51 +0100
Message-ID: <008601bf7f75$7fe49050$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: How are Naming Domains identified?
Date: Fri, 25 Feb 2000 09:48:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA12322

Hi,
I would like to get some feedback on how naming domains are identified. 
Let's say that a DN is "CN=John Doe; SN=1234".   IMO that DN  (hopefully) expresses
an unmistakable identity witin a certain naming domain but nothing prevent a CA supporting
another naming domain to use the same DN for the same or another entity.

Background: Extract from a rather heated discussion regarding serialNumbers etc:

>>Anders wrote:

>>What is missing from the current suggestion is a Naming Domain definition.
>>I can just find two variants: Either the naming domain is marked as internal/CA
>>and does not have to be known outside, or the CA issues certificates to
>>an external naming domain like "registered Citizen of XYZ". The latter should
>>require an officially registered value of some kind to be interoperable among
>>competing CAs,

>Steve wrote:

>I think that your suggestion for a name domain definition is further evidence that the 
>identifiers that you are referring to are not really DNs!


Anders



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11824 for <[e-mail]>; Fri, 25 Feb 2000 00:43:45 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <FNY37Z6D>; Fri, 25 Feb 2000 09:47:23 +0100
Message-ID: <C0E81C20AD21D311BDB200805FCCD9412F5DD6@AUNT9>
From: Simon Tardell <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, [e-mail]
Subject: OCSP, historical answers
Date: Fri, 25 Feb 2000 09:47:03 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

> Hi Paul,
>     Just one correction - OCSP can tell you of the historical
> status of a cert - there is an ArchiveCutoff mechanism. If your
> cert expired after ArchiveCutoff, then the status is as indicated
> in the response.

Yes, but what about a certificate that was put on-hold for a certain period
but then made valid again? There are of course ways to solve this using
timestamping, but it seems like an omission that neither OCSP nor CRLs have
a mechanism for giving a full account of the revocation history of a
certificate. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA06585 for <[e-mail]>; Thu, 24 Feb 2000 21:46:31 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 22:50:15 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 24 Feb 2000 22:50:02 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Tammy Green" <[e-mail]>
Subject: Re: What if the CRL distribution points for a CA change?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA06586

Serves me right for not paying adequate attention to the cc list.  I thought I was responding to an internal Novell discussion, and did not intend to post such a  flip response to this list, nor to necessarily suggest that only LDAP forms of CRL distribution points should be used.

In the more general context, I think Tammy's points are worth discussing.

Bob

>>> "Bob Jueneman" <[e-mail]> 02/24/00 09:55PM >>>
Don't do that?

I.e., :

1.  Don't issue certificates containing multiple distribution points.

2.  If issuing certificates with multiple distribution points is absolutely necessary (for some reason I can't quite fathom), don't change the distribution points unless you are prepared to implement option b.

If we restrict the type of distribution points to LDAP queries, wouldn't it be possible to remap the DNS name of the server as might be required for load balancing, leaving the LDAP query itself unmodified?  Doesn't this eliminate the entire problem?

Bob



>>> Tammy Green 02/24/00 08:58PM >>>
Say a CA begins minting certificates with distribution points A, B, and C in the certificates.  It issues 10 certificates.  Then, at time t1, it changes the distribution points to A, D, and E and issues 10 more certificates.

Now say that at time t2 certificate 1 was revoked as well as certificate 11.  What should the CA do when it comes time to issue the CRL?  [Assume here that the CA is only issuing a basic CRL that is not subdivided by reason codes, etc.]  It appears that there are two options.

(a)  Issue one CRL containing entries for certificate 1 and 11.  Post that CRL to distribution points A, B, C, D, and E.

(b)  Issue one CRL containing entries for certificate 1 and 11 and post that CRL to distribution point A.  Then issue another CRL containing an entry for only certificate 1 and post that CRL to distribution points B and C.  Finally issue yet another CRL containing an entry for only certificate 10 and post that CRL to distribution points D and E.

Option a has the disadvantage of causing needless bloat to the CRLs posted on distribution points B, C, D, and E:  no one will look for revocation information about certificate 1 on distribution point D or E, and, likewise, no one will look for revocation information about certificate 11 on distribution point B or C.  Option a does have the advantage of being far easier to implement, however.

Option b has the disadvantage of being much more complex.  And, each time the set of distribution points is modified, the complexity increases as does the time required to generate all of the CRLs which are required.  However, the advantage is that the CRLs that are posted to the distribution points contain only useful information.

Are there other solutions?  Preferences?  Implementations?  Guidelines?


Tammy Green
[e-mail] 
Software Engineer
Novell, Inc.




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA04547 for <[e-mail]>; Thu, 24 Feb 2000 20:52:22 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 21:56:06 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 24 Feb 2000 21:55:58 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, "Tammy Green" <[e-mail]>
Subject: Re: What if the CRL distribution points for a CA change?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id UAA04548

Don't do that?

I.e., :

1.  Don't issue certificates containing multiple distribution points.

2.  If issuing certificates with multiple distribution points is absolutely necessary (for some reason I can't quite fathom), don't change the distribution points unless you are prepared to implement option b.

If we restrict the type of distribution points to LDAP queries, wouldn't it be possible to remap the DNS name of the server as might be required for load balancing, leaving the LDAP query itself unmodified?  Doesn't this eliminate the entire problem?

Bob



>>> Tammy Green 02/24/00 08:58PM >>>
Say a CA begins minting certificates with distribution points A, B, and C in the certificates.  It issues 10 certificates.  Then, at time t1, it changes the distribution points to A, D, and E and issues 10 more certificates.

Now say that at time t2 certificate 1 was revoked as well as certificate 11.  What should the CA do when it comes time to issue the CRL?  [Assume here that the CA is only issuing a basic CRL that is not subdivided by reason codes, etc.]  It appears that there are two options.

(a)  Issue one CRL containing entries for certificate 1 and 11.  Post that CRL to distribution points A, B, C, D, and E.

(b)  Issue one CRL containing entries for certificate 1 and 11 and post that CRL to distribution point A.  Then issue another CRL containing an entry for only certificate 1 and post that CRL to distribution points B and C.  Finally issue yet another CRL containing an entry for only certificate 10 and post that CRL to distribution points D and E.

Option a has the disadvantage of causing needless bloat to the CRLs posted on distribution points B, C, D, and E:  no one will look for revocation information about certificate 1 on distribution point D or E, and, likewise, no one will look for revocation information about certificate 11 on distribution point B or C.  Option a does have the advantage of being far easier to implement, however.

Option b has the disadvantage of being much more complex.  And, each time the set of distribution points is modified, the complexity increases as does the time required to generate all of the CRLs which are required.  However, the advantage is that the CRLs that are posted to the distribution points contain only useful information.

Are there other solutions?  Preferences?  Implementations?  Guidelines?


Tammy Green
[e-mail] 
Software Engineer
Novell, Inc.



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01337 for <[e-mail]>; Thu, 24 Feb 2000 19:58:01 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLXWS3>; Thu, 24 Feb 2000 19:53:04 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 19:52:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Alistair,
    Didn't you want to scrap OCSP entirely, anyway? :-)

How a VA gets and keeps access to its revocation data doesn't
need to involve access to the CAs repository. It could keep the
data locally/in memory.

Yes, I agree, you could return tryLater, the main thing I would
question is the value of making that a requirement on the
VA.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Grant, Alistair [mailto:[e-mail]]
> Sent: Thursday, February 24, 2000 3:54 PM
> To: Ambarish Malpani; '[e-mail]'
> Subject: RE: German Law and OCSP
> 
> 
> Ambarish Malpani wrote:
> > II. The "publicly available" clause needs to be carefully
> > interpreted. I don't think it makes sense to force the VA
> > to try and retrieve the certificate in question from a
> > directory, because you *will* hit the situation where a
> > certificate was, in fact correctly issued, but because of
> > some transient network/machine problem, the VA can't get to
> > the repository for an instant in time. In that case, should
> > the VA return a status of bad/revoked/unknown/good? Which of
> > the responses is "correct"?
> 
> If we take this reasoning one step further, the responder 
> can't get the CRL
> because of some transient network/machine problem, what 
> should be done?
> Taking this to the (ridiculous) extreme, does that mean we 
> shouldn't force
> the responder to try and retrieve the CRL?
> 
> I think the common answer will be that the responder returns 
> unknown or
> tryLater until the CRL becomes available.
> 
> I don't believe that this particular argument holds against 
> requiring the
> responder to retrieve the certificate as part of the status check.
> 
> 
> Cheers,
> 
> 
> Alistair Grant
> Project Manager - Development
> Computer Associates, OpenDirectory Lab
> Melbourne, Victoria, Australia
> Phone:	[phone]
> Mobile:	[phone]
> Fax:	[phone]
> E-Mail:	[e-mail]
> 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA00978 for <[e-mail]>; Thu, 24 Feb 2000 19:55:26 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 24 Feb 2000 20:58:47 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 24 Feb 2000 20:58:37 -0700
From: "Tammy Green" <[e-mail]>
To: <[e-mail]>
Cc: "Bob Jueneman" <[e-mail]>
Subject: What if the CRL distribution points for a CA change?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA00980

Say a CA begins minting certificates with distribution points A, B, and C in the certificates.  It issues 10 certificates.  Then, at time t1, it changes the distribution points to A, D, and E and issues 10 more certificates.

Now say that at time t2 certificate 1 was revoked as well as certificate 11.  What should the CA do when it comes time to issue the CRL?  [Assume here that the CA is only issuing a basic CRL that is not subdivided by reason codes, etc.]  It appears that there are two options.

(a)  Issue one CRL containing entries for certificate 1 and 11.  Post that CRL to distribution points A, B, C, D, and E.

(b)  Issue one CRL containing entries for certificate 1 and 11 and post that CRL to distribution point A.  Then issue another CRL containing an entry for only certificate 1 and post that CRL to distribution points B and C.  Finally issue yet another CRL containing an entry for only certificate 10 and post that CRL to distribution points D and E.

Option a has the disadvantage of causing needless bloat to the CRLs posted on distribution points B, C, D, and E:  no one will look for revocation information about certificate 1 on distribution point D or E, and, likewise, no one will look for revocation information about certificate 11 on distribution point B or C.  Option a does have the advantage of being far easier to implement, however.

Option b has the disadvantage of being much more complex.  And, each time the set of distribution points is modified, the complexity increases as does the time required to generate all of the CRLs which are required.  However, the advantage is that the CRLs that are posted to the distribution points contain only useful information.

Are there other solutions?  Preferences?  Implementations?  Guidelines?


Tammy Green
[e-mail] 
Software Engineer
Novell, Inc.



Received: from gnu.IN-Berlin.DE (gnu.in-berlin.de [192.109.42.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21545 for <[e-mail]>; Thu, 24 Feb 2000 17:55:39 -0800 (PST)
Received: from hirsch.in-berlin.de ([e-mail] [192.109.42.6]) by gnu.IN-Berlin.DE (8.9.3/8.9.3) with ESMTP id CAA03600; Fri, 25 Feb 2000 02:59:42 +0100 (CET) (envelope-from aurora.in-berlin.de![e-mail])
Received: by hirsch.in-berlin.de (Smail3.2)  from  aurora.in-berlin.de with uucp id <m12OA2e-000gjQC>; Fri, 25 Feb 2000 02:59:40 +0100 (CET)
Received: by aurora.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.14) id <[e-mail]>; Fri, 25 Feb 2000 02:56 MET
Message-Id: <[e-mail]>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
In-Reply-To: <[e-mail]>
X-Nextstep-Mailer: Mail 3.3 [m68k] (Enhance 2.2.3, Nov 1999)
Received: by NeXT.Mailer (1.118.2)
From: Ingmar Camphausen <[e-mail]>
Date: Fri, 25 Feb 2000 02:56:46 +0100
To: Ambarish Malpani <[e-mail]>
Subject: Re: German Law and OCSP
cc: [e-mail]
Reply-To: [e-mail]
References: <[e-mail]>
Organization: Individual Network Berlin
Priority: normal

Ambarish,

> P.S. I, too, would appreciate pointers to English versions of both the
> German and Italian Digital Signature laws.
[...]
> >> Another misunderstanding seems to be the role of the CRL in German Law.
[...]
> > This is _5(1) in my (English) copy dated 1 August 1997.  Is there a
> > later version?
[...]
> > Do you have a reasonable English translation of the Italian law - or a
> > link to a translation?


The German wording of the Signaturgesetz ("German Digital Signature Act"
-- SigG) as passed by the German Bundestag (Parliament) on 13 June 1997
is online in HTML and PDF format at

	http://www.iid.de/rahmen/iukdgbt.html#a3

The English version (or translation?) of the German SigG, dated
"August 1 1997", is at

	http://www.iid.de/rahmen/iukdgebt.html#a3

As this is part of the online presence "Initiative Information Society
Germany" by the German Federal Government (Federal Ministry for Education
and Research), the German version of the SigG at the URL above should be
the exact wording of the Act.

The Act has not been changed or amended since it became effective.
(It is under review now, as Stefan Kelm mentioned earlier, and will be
modified and/or amended in some points to reflect the changes required
by the European Directive on electronic signatures "Council of 13 December
1999 on a Community framework for electronic signatures" -- online at
http://europa.eu.int/eur-lex/en/dat/2000/l_013/l_01320000119en00120020.pdf)


At http://www.iid.de/iukdg/sigve.html you can find an English version of
the German "Signaturverordnung" (Digital Signature Ordinance, SigV) that
concretizes some of the technical details intentionally omitted from the
SigG itself in order to make the SigG more "generic".


These -- and other -- documents related to digital signature legislation
in Germany and on the European level are also available from our project
FTP server at

	ftp://ftp.pca.dfn.de/pub/pca/docs/SigG/
	ftp://ftp.pca.dfn.de/pub/pca/docs/SigG/Europe/

		.	.	.

Regarding an English version of the _Italian_ Digital Signature
legislation, I can only point you to the section covering Italy in
Simone van der Hof's "Digital Signature Law Survey", online at

	http://cwis.kub.nl/~frw/people/hof/DS-lawsu.htm

It provides a nice (English) overview of how the Italian Digital
Signature legislation took place, as well as links to two English
texts about its unfolding.

Please note that some of the hyperlinks in that section have slightly
changed! The "Presidential Decree No. 513 of 10 November 1997" can be
found at

	http://www.aipa.it/english[4/law[3/law5997.asp

now, and the "Regulations establishing criteria and means for implementing
Section 15(2) of Law No. 59 of 15 March 1997 concerning the creation,
storage and transmission of documents by means of computer-based or
telematic systems" have moved to

	http://www.aipa.it/english[4/law[3/pdecree51397.asp


Hope this helps,

    Ingmar


--
Ingmar Camphausen    PGP key: 'finger [e-mail]' or via keyserver
DFN-PCA (Policy CA, German Research Network)                [e-mail]
Vogt-Koelln-Str. 30                                    http://www.pca.dfn.de/
D-22527 Hamburg, Germany                       +49.40.42883-2262 / Fax: -2241


Received: from svr1.iei.net (svr1.iei.net [209.131.216.204]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20642 for <[e-mail]>; Thu, 24 Feb 2000 16:33:36 -0800 (PST)
Received: from LCUNVBBW (tc3-002.dip.iei.net [209.131.197.130]) by svr1.iei.net (8.8.7/8.6.9) with SMTP id TAA07620 for <[e-mail]>; Thu, 24 Feb 2000 19:35:33 -0500
From: "Ariel Silverstone" <[e-mail]>
To: <[e-mail]>
Subject: Unsub
Date: Thu, 24 Feb 2000 19:38:15 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

How may I Unsubscribe?




Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19679 for <[e-mail]>; Thu, 24 Feb 2000 15:48:17 -0800 (PST)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <FC0WQT9V>; Fri, 25 Feb 2000 10:53:36 +1100
Message-ID: <[e-mail]>
From: "Grant, Alistair" <[e-mail]>
To: Ambarish Malpani <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Fri, 25 Feb 2000 10:53:58 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish Malpani wrote:
> II. The "publicly available" clause needs to be carefully
> interpreted. I don't think it makes sense to force the VA
> to try and retrieve the certificate in question from a
> directory, because you *will* hit the situation where a
> certificate was, in fact correctly issued, but because of
> some transient network/machine problem, the VA can't get to
> the repository for an instant in time. In that case, should
> the VA return a status of bad/revoked/unknown/good? Which of
> the responses is "correct"?

If we take this reasoning one step further, the responder can't get the CRL
because of some transient network/machine problem, what should be done?
Taking this to the (ridiculous) extreme, does that mean we shouldn't force
the responder to try and retrieve the CRL?

I think the common answer will be that the responder returns unknown or
tryLater until the CRL becomes available.

I don't believe that this particular argument holds against requiring the
responder to retrieve the certificate as part of the status check.


Cheers,


Alistair Grant
Project Manager - Development
Computer Associates, OpenDirectory Lab
Melbourne, Victoria, Australia
Phone:	[phone]
Mobile:	[phone]
Fax:	[phone]
E-Mail:	[e-mail]



Received: from webserver.1ecc.com (IDENT:[e-mail] [206.170.148.220]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19237 for <[e-mail]>; Thu, 24 Feb 2000 15:35:19 -0800 (PST)
Received: (from nobody@localhost) by webserver.1ecc.com (8.9.3/8.9.3) id PAA08540; Thu, 24 Feb 2000 15:32:46 -0800
Date: Thu, 24 Feb 2000 15:32:46 -0800
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: You are unsubscribed!

You have been unsubscribed from the First e-Commerce Corp Mailing List and if you ever
wish to re-subscibe just do so at our website.

Albert



Received: from webserver.1ecc.com (IDENT:[e-mail] [206.170.148.220]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18991 for <[e-mail]>; Thu, 24 Feb 2000 15:31:05 -0800 (PST)
Received: (from nobody@localhost) by webserver.1ecc.com (8.9.3/8.9.3) id PAA07597; Thu, 24 Feb 2000 15:28:30 -0800
Date: Thu, 24 Feb 2000 15:28:30 -0800
Message-Id: <[e-mail]>
Content-type: text/html
From: [e-mail]
To: [e-mail]
Subject: Legal Web Site

Still don't have an Interactive WEB Site? Have Directory Listing or a Web Page?


Almost everyone has joined in on the Internet revolution, including you, but what is in store for the future of the World Wide Web?  Traditional advertising will soon be completely swept away by the more powerful, more effective, more cost-conscious Internet.  

First E-Commerce Corporation specializes in designing interactive web sites for the legal community. Whether you already have a web page or simply advertise on the 'net, you are probably not seeing the results you'd like.   Most legal pages contain generic information and are difficult to locate. The key to the success of a web site is the amount of traffic that it brings. With our experienced web site developers and graphic designers, we can help you in creating greater visibility, expanding your client base, as well as provide a means for increasing services to existing clients. 

The sites that we design are not simply informative, but interactive as well.  Visiting your site should be something that the visitor enjoys experiencing again and again, a reference tool for both you and your clients.  Our sites send the message that your Firm is innovative and can use the most up to date technology to tackle their legal issues.  We hold the winning formula that will prove you are one step ahead and can offer the quickest, easiest, most cost-effective 
services to your clients.  

Our web site package will enable your clients access to forms and documents that can be downloaded from your site 24 hours a day.  You will be able to automatically bill clients for these additional services, while sending the message that your assistance is always available.  This will increase your billable hours without increasing the man-hours to do it. The Internet revolution has carried over to the courts as well, and our web sites enable you and your clients to file legal documents electronically.   Our database-enabled site is the first of it's kind, and allows easy access to legal forms and thousands of legal documents for both attorneys and clients.  

The First e-Commerce Corporation package is revolutionizing the way law firms conduct their daily communications with clients.  Come join the revolution and let us develop a site for your Firm that makes you stand out from the crowd.


Contact:		Lonnie Brookins
Tel:			[phone] x101
Fax:			[phone]
E-Mail			[e-mail]

www.firstecc.com

   <BR><BR>
---------------------------------------------------------------------<BR>
We hope you have found this information useful. If you have any
suggestions or topics you would like to read more about, please let us know. If you would like to
unsubscribe, see the instructions below. Thank you and have a great day
and best wishes in
your online business!
 
REMOVAL INSTRUCTIONS:
Click on the link below to be removed from the 
First e-Commerce Corp Mailing List.<BR><BR>

<A HREF="http://www.firstecc.com/cgi-bin/mailmachine.cgi?[e-mail]">http://www.firstecc.com/cgi-bin/mailmachine.cgi?[e-mail]</A><BR>

This message is sent in compliance of the new email bill
section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,
further transmissions to you by the sender of this email may be
stopped at no cost to you.This message is not intended for
residents in the State of WA, CA & VA Screening of addresses
has been done to the best of our technical ability.If you are a 
Washington, Virginia, or California resident please remove
yourself.

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


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18534 for <[e-mail]>; Thu, 24 Feb 2000 15:07:51 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLXVZ8>; Thu, 24 Feb 2000 15:02:54 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: [e-mail]
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 15:02:48 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA18535

Hi Paul,
    Just one correction - OCSP can tell you of the historical
status of a cert - there is an ArchiveCutoff mechanism. If your
cert expired after ArchiveCutoff, then the status is as indicated
in the response.

Regards,
Ambarish

P.S. I, too, would appreciate pointers to English versions of both
the German and Italian Digital Signature laws.

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Paul Halliden [mailto:[e-mail]]
> Sent: Thursday, February 24, 2000 8:53 AM
> To: 'Hesse, Johan'; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: German Law and OCSP
> 
> 
> > It seems that there are a lot of confusions regarding some terms 
> > in the German Law.  
> Agreed ;)
> 
> [snip]
> 
> > I think the confusion springs from legal terms. In the above 
> > mentioned example the technical term of *valid* for a certificate 
> > would be the moment of the signing with the signing key. 
> Technically a certificate is valid from the date and time 
> contained in the
> ASN.1 element "notBefore" in the "Validity" sequence of the 
> X.509 structure.
> This may or may not be the time of signing by the CA.  
> Indeed, it may be
> delayed with respect to time of signing to cope with the scenario you
> describe in your later mail.  This is the same as the process 
> known as "Thro
> dating" used by credit card companies to protect against the risks you
> mention.
> 
> > The legal term assumes the publishing of the certificate.
> >
> > Another misunderstanding seems to be the role of the CRL in 
> German Law. 
> > Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> > to prove that a cert was not valid at a certain date is to provide
> > a CRL (or a CSL!!!) that includes it." The German Law requires
> > only the *checkability* of the status of a certificate for anybody 
> > to any time (§4 SigG). 
> This is §5(1) in my (English) copy dated 1 August 1997.  Is 
> there a later
> version?  More importantly, it was explained to me that the 
> German model
> needed to know if a certificate was valid at the time that 
> the corresponding
> signature key was originally used and not at the time the request for
> validation is performed.  This is because one might be 
> checking a legal
> document that is tens of years old.  Is that what you mean by 
> "to any time"?
> 
> > The interoperability schemes (SigI A5) propose OCSP. 
> As I understand it, OCSP is designed to tell you status now 
> not status at
> some previous date.  If so, is this another issue with German 
> Law and OCSP?
> 
> > The status *suspension* isn't allowed according to the German Law, 
> > in comparison with Italian law which requires a CRL (Art. 29 par. 3)
> > and the possibility of suspension (Art. 33).
> Do you have a reasonable English translation of the Italian 
> law - or a link
> to a translation?
> 


Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA12911 for <[e-mail]>; Thu, 24 Feb 2000 08:46:58 -0800 (PST)
Message-ID: <[e-mail]>
From: Paul Halliden <[e-mail]>
To: "'Hesse, Johan'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 16:52:50 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA12912

> It seems that there are a lot of confusions regarding some terms 
> in the German Law.  
Agreed ;)

[snip]

> I think the confusion springs from legal terms. In the above 
> mentioned example the technical term of *valid* for a certificate 
> would be the moment of the signing with the signing key. 
Technically a certificate is valid from the date and time contained in the
ASN.1 element "notBefore" in the "Validity" sequence of the X.509 structure.
This may or may not be the time of signing by the CA.  Indeed, it may be
delayed with respect to time of signing to cope with the scenario you
describe in your later mail.  This is the same as the process known as "Thro
dating" used by credit card companies to protect against the risks you
mention.

> The legal term assumes the publishing of the certificate.
>
> Another misunderstanding seems to be the role of the CRL in German Law. 
> Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> to prove that a cert was not valid at a certain date is to provide
> a CRL (or a CSL!!!) that includes it." The German Law requires
> only the *checkability* of the status of a certificate for anybody 
> to any time (§4 SigG). 
This is §5(1) in my (English) copy dated 1 August 1997.  Is there a later
version?  More importantly, it was explained to me that the German model
needed to know if a certificate was valid at the time that the corresponding
signature key was originally used and not at the time the request for
validation is performed.  This is because one might be checking a legal
document that is tens of years old.  Is that what you mean by "to any time"?

> The interoperability schemes (SigI A5) propose OCSP. 
As I understand it, OCSP is designed to tell you status now not status at
some previous date.  If so, is this another issue with German Law and OCSP?

> The status *suspension* isn't allowed according to the German Law, 
> in comparison with Italian law which requires a CRL (Art. 29 par. 3)
> and the possibility of suspension (Art. 33).
Do you have a reasonable English translation of the Italian law - or a link
to a translation?


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12610 for <[e-mail]>; Thu, 24 Feb 2000 08:39:07 -0800 (PST)
Received: from HYDRA ([195.198.186.76]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA04564; Thu, 24 Feb 2000 17:46:34 +0100
Received: by HYDRA with Microsoft Mail id <01BF7EED.69EC8380@HYDRA>; Thu, 24 Feb 2000 17:34:33 +0100
Message-ID: <01BF7EED.69EC8380@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'David P. Kemp'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 17:34:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

<snip>

>>PS Steve, do you prefer that a solution according to my and Denis lines are
>>taken to PKI-FORUM rather than developed here?  I don't care where as
>>long as it gets done.  DS

>Is this a trick question?  Is it really an offer for you to move your 
>campaign for changes to ITU and IETF standards to an industry 
>consortium? How can I say no?

OK, I will not continue to push Plug'nPlay Certificates in IETF.
A great victory for purity!  "Consensus" rules!

You are free to continue to outlaw DN interpretation support schemes (should include the latest
suggestions by Stefan and David Kemp) in the same way as dnQualifier in spite of the fact that
both belong to current practice and work just fine.

And we will get International standards that contain phrases like "certificates must be compared with care".

Looks like a good time to invest in a PKI-consulting business.  :-)

Anders



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11870 for <[e-mail]>; Thu, 24 Feb 2000 08:00:31 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <FNY37WJY>; Thu, 24 Feb 2000 17:04:04 +0100
Message-ID: <C0E81C20AD21D311BDB200805FCCD9412F5DD1@AUNT9>
From: Simon Tardell <[e-mail]>
To: "'Hesse, Johan'" <[e-mail]>, [e-mail]
Subject: RE: OCSP and German Law
Date: Thu, 24 Feb 2000 17:04:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7EE0.C4E602F0"

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

------_=_NextPart_001_01BF7EE0.C4E602F0
Content-Type: text/plain;
	charset="iso-8859-1"

My comments below.

Hello! 

I agree to Stefan, I bet a box of beer that the "validity model" in the
German Law won't change. 

We accompanied TrustCenter which are conform to German Law and we saw that
this validity model has an advantage (maybe this is the rational of the
model). Since everyone seems to be unhappy with this validity model lets
mention the advantage to the honour of the good old law.

But please don't flame me, because I'm sure that there are other (better?)
possibilities. 

The advantage is more or less of legal and/or organizational nature. If the
CA signs a certificate, the PSE (e.g. your smart card with your *private*
key) has to be delivered in a secure way to the owner. 

In technical terms the certificate is almost valid (but not in legal terms).
But the PSE hasn't handed out to the owner yet, - with all possibilities of
abuse (I know there are ways to handle it in another way). But if you wait
until the owner proofs that he received the PSE, to say the certificate is
valid you avoid this insecure time gap. The validation is manifested by
publishing the certificate.

So I hope you see the rational of this validity model. 

I will not challenge your bet, but: This is not a good reason to mandate
that a validation authority must know if a certificate was ever issued. To
make sure that the certificate is not valid between the point in time where
it is issued and where the corresponding token is confirmed received by the
intended end-user you simply put it on-hold (revoke it with reason code
on-hold) until such confirmation is received. This is in my mind a rather
good way of using "suspension" (as compared to some of the more construed
scenarios we've been hearing). It was brought up that the German law does
not allow suspension. This is almost true -- but a certificate that has been
issued but not yet entered into the directory (SigG) is in fact suspended,
so for this exact purpose it seems ok. 

I think the point made by earlier by Andreas makes a lot of sense:

Another point is that the compromise of a CA key may be a very seldom event
but the potential cost, even with a desaster plan in place (anyone heard
about one from any CA?) it may be desirable to have simple technical
fallback position.

If the CA keys are compromised it can be prohibitingly expensive to replace
all certificates, especially since smart cards are mostly off-line. If there
is an independent notary service (which the directory (SigG) essentially is)
that can vouch for that a certificate was (or was not) issued before the
compromise of the CA keys, the tokens can be continued to be used. And, I
guess, there can be any number of "backup" directory (SigG) services,
improving reliability.

Simon.

Simon Tardell, Software Architect, iD2 Technologies 
[e-mail],  <http://www.id2tech.com/>
http://www.iD2tech.com/ 
voice [phone], cell [phone], fax [phone] 
European IT-prize grand winners 1998 --  <http://www.it-prize.org/>
http://www.it-prize.org 
AU-System Group Swedish IT-company of the year 1999 


------_=_NextPart_001_01BF7EE0.C4E602F0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Re: OCSP and German Law</TITLE>

<META content="MSHTML 5.00.2919.3800" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>My 
comments below.</SPAN></FONT></P>
<P><EM><FONT face=Arial size=2>Hello!</FONT> </EM></P>
<P><EM><FONT face=Arial size=2>I agree to Stefan, I bet a box of beer that the 
"validity model" in the German Law won't change.</FONT> </EM></P>
<P><EM><FONT face=Arial size=2>We accompanied TrustCenter which are conform to 
German Law and we saw that this validity model has an advantage (maybe this is 
the rational of the model). Since everyone seems to be unhappy with this 
validity model lets mention the advantage to the honour of the good old 
law.</FONT></EM></P>
<P><EM><FONT face=Arial size=2>But please don't flame me, because I'm sure that 
there are other (better?) possibilities. </FONT></EM></P>
<P><EM><FONT face=Arial size=2>The advantage is more or less of legal and/or 
organizational nature. If the CA signs a certificate, the PSE (e.g. your smart 
card with your *private* key) has to be delivered in a secure way to the owner. 
</FONT></EM></P>
<P><EM><FONT face=Arial size=2>In technical terms the certificate is almost 
valid (but not in legal terms). But the PSE hasn't handed out to the owner yet, 
- with all possibilities of abuse (I know there are ways to handle it in another 
way). But if you wait until the owner proofs that he received the PSE, to say 
the certificate is valid you avoid this insecure time gap. The validation is 
manifested by publishing the certificate.</FONT></EM></P>
<P><EM><FONT face=Arial size=2>So I hope you see the rational of this validity 
model.</FONT> </EM></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>I will 
not challenge your bet, but: This is not a good reason to mandate that a 
validation authority must&nbsp;know&nbsp;if a certificate was ever issued. To 
make sure that the&nbsp;certificate is not valid between the point in time where 
it is issued and where&nbsp;the corresponding token is&nbsp;confirmed received 
by the intended end-user you simply put it on-hold (revoke it with reason code 
on-hold) until such confirmation is received. This is in my mind a rather good 
way of using "suspension" (as compared to some of the more construed scenarios 
we've been hearing). It was brought up that the German law does not allow 
suspension. This is almost true -- but a certificate that has been issued but 
not yet entered into the directory (SigG) is in fact suspended, so for this 
exact purpose it seems ok. </SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>I think 
the point made by earlier by Andreas makes a lot of 
sense:</SPAN></FONT></P><SPAN class=865014115-24022000>
<P><FONT size=2><EM><FONT face=Arial>Another point is that the compromise of a 
CA key may be a very seldom<SPAN class=865014115-24022000> </SPAN>event but the 
potential cost, even with a desaster plan in place (anyone<SPAN 
class=865014115-24022000> </SPAN>heard about one from any CA?) it may be 
desirable to have simple</FONT><FONT face=Arial><SPAN class=865014115-24022000> 
</SPAN>technical fallback position.</FONT></EM></FONT></P></SPAN>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>If the 
CA keys are compromised it can be prohibitingly expensive to replace all 
certificates, especially since smart cards are mostly off-line. If there is an 
independent notary service (which the directory (SigG) essentially is) that can 
vouch for that a certificate was (or was not) issued before the compromise of 
the CA keys, the tokens can be continued to be used. And, I guess, there can be 
any number of "backup" directory (SigG) services, improving 
reliability.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN 
class=865014115-24022000>Simon.</SPAN></FONT></P>
<P><FONT size=2><FONT face=Arial>Simon Tardell, Software Architect, iD2 
Technologies</FONT></FONT> <BR><FONT face=Arial 
size=2>[e-mail], <A href="http://www.id2tech.com/" 
target=_blank><FONT color=#000000>http://www.iD2tech.com/</FONT></A></FONT> 
<BR><FONT face=Arial size=2>voice [phone], cell [phone], fax +46 8 
7267912</FONT> <BR><FONT face=Arial size=2>European IT-prize grand winners 1998 
-- <A href="http://www.it-prize.org/" target=_blank><FONT 
color=#000000>http://www.it-prize.org</FONT></A></FONT> <BR><FONT face=Arial 
size=2>AU-System Group Swedish IT-company of the year 1999</FONT> 
</P></DIV></BODY></HTML>

------_=_NextPart_001_01BF7EE0.C4E602F0--


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11603 for <[e-mail]>; Thu, 24 Feb 2000 07:49:06 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLX4FJ>; Thu, 24 Feb 2000 07:44:04 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 07:44:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA11604

Hi Guys,
    As I understand it, the requirements for a certificate to
be considered valid according to the German Digital Signature
Act are:

1. The certificate has been created and signed by the CA
2. It is publicly available (if the certificate holder allows).

There was another benefit desired, where a client be able to
query the status of a certificate, where, while querying, it
might not have the CA's public key.


This was translated into an OCSP request where:
a. The request may be made with the hash of the CA's public key
set to 0/all 0's
b. The response would contain the real hash of the CA's public key
c. The responder (VA) verify that the cert was contained in "the"
directory.

Comments
--------
- I believe the requirement to force the VA to check that the
cert is in the directory was to prevent the VA from issuing
incorrect responses (where a cert has been signed, but not
added in the directory)

Issues
------
I. IMPORTANT: If a client be allowed to make a query for a
certificate where it hasn't checked the signature, it could
be making a query for a certificate that doesn't exist (because
the signature on it is bad). The responder might still say the
certificate is good, because, ANOTHER CERTIFICATE WITH THE SAME
SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!

II. The "publicly available" clause needs to be carefully
interpreted. I don't think it makes sense to force the VA
to try and retrieve the certificate in question from a
directory, because you *will* hit the situation where a
certificate was, in fact correctly issued, but because of
some transient network/machine problem, the VA can't get to
the repository for an instant in time. In that case, should
the VA return a status of bad/revoked/unknown/good? Which of
the responses is "correct"?

Recommendations
---------------
i) Require clients to verify the signature on the certificate
and its validity (ie. in the notBefore and notAfter period)
when the make the query [caveat: the cert might have expired,
in which case you need to check the ArchiveCutoff in the response].
This job needs to be done by the client to ensure that the
query is a reasonable one.

ii) Enforce the publicly available requirement by policy and
procedure. Don't try to enforce that with software.

Does this make sense?

Regards,
Ambarish


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Stefan Kelm [mailto:[e-mail]]
> Sent: Thursday, February 24, 2000 5:48 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: German Law and OCSP
> 
> 
> Denis,
> 
> > > Once such a division is made technically, it was extended 
> to the idea
> > > that a certificate should only be valid once it is inserted in the
> > > information service database.
> >
> > I do not understand. To be "valid" a certificate does not (even)
> > have to be published. It may be given back to the user who may
> > decide to send it to whatever entity he wishes.
> 
> you're certainly right. However, the German Digital Signature 
> Act states:
> [from http://www.iid.de/rahmen/iukdgebt.html#a3]
> 
> § 5: Issue of Certificates
> 
> (1) The certification authority shall reliably establish the 
> identity of persons applying for a
> certificate. It shall confirm the assignment of a public 
> signature key to an identified person
> by a signature key certificate which, together with any 
> attribute certificates, shall be kept
> available for verification and, with the consent of the owner 
> of the signature key, for
> retrieval at all times and for everyone over publicly 
> available telecommunication links.
> 
> The magic statement here is "...shall be kept available for 
> verification...
> at all times...". Therefore, a certificate implicitly is 
> valid once it is
> made available (from the CA's repository) for verification. Like it or
> not (I don't) - that's the way the validity model was chosen 
> to be. E.g., I've
> been issued one of the very few certificates issued according 
> to the law
> but since it has not been published yet it is not valid in the sense
> of the law...
> 
> The law currently is under evaluation and will be revised later this
> year. It's highly unlikely that they're going to change this validity
> model, though.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________
> ________________
> Stefan Kelm            PGP key: "finger [e-mail]" 
> or via key server
> DFN-PCA                                                      
> <[e-mail]>
> Vogt-Koelln-Str. 30                               
> http://www.pca.dfn.de/~kelm/
> 22527 Hamburg (Germany)                   Tel: [phone] 
> 83-2262 / Fax: -2241
> 


Received: from mail-int.cubis.de (maildt.cubis.de [212.185.174.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11221 for <[e-mail]>; Thu, 24 Feb 2000 07:30:12 -0800 (PST)
Received: from ex-mail.cubis.de (ex-mail.cubis.de [10.31.4.65]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id QAA20008 for <[e-mail]>; Thu, 24 Feb 2000 16:35:23 +0100 (MET)
Received: by ex-mail.cubis.de with Internet Mail Service (5.5.2650.21) id <1PRNDYFW>; Thu, 24 Feb 2000 16:33:17 +0100
Message-ID: <[e-mail]>
From: "Hesse, Johan" <[e-mail]>
To: [e-mail]
Subject: Re: OCSP and German Law
Date: Thu, 24 Feb 2000 16:32:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7EDC.787D0640"

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

------_=_NextPart_001_01BF7EDC.787D0640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello!

I agree to Stefan, I bet a box of beer that the "validity model" in the
German Law won't change.

We accompanied TrustCenter which are conform to German Law and we saw =
that
this validity model has an advantage (maybe this is the rational of the
model). Since everyone seems to be unhappy with this validity model =
lets
mention the advantage to the honour of the good old law.
But please don't flame me, because I'm sure that there are other =
(better?)
possibilities.=20

The advantage is more or less of legal and/or organizational nature. If =
the
CA signs a certificate, the PSE (e.g. your smart card with your =
*private*
key) has to be delivered in a secure way to the owner.=20

In technical terms the certificate is almost valid (but not in legal =
terms).
But the PSE hasn't handed out to the owner yet, - with all =
possibilities of
abuse (I know there are ways to handle it in another way). But if you =
wait
until the owner proofs that he received the PSE, to say the certificate =
is
valid you avoid this insecure time gap. The validation is manifested by
publishing the certificate.

So I hope you see the rational of this validity model.

   Cheers,

               Johan

P.s.: I wait if somone wants to bet. I propose we drink the beer =
together, -
lets say at the CeBit 2001.

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : [phone]
> Fax   : [phone]
> mailto:[e-mail]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7EDC.787D0640
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: OCSP and German Law</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree to Stefan, I bet a box of beer =
that the &quot;validity model&quot; in the German Law won't =
change.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We accompanied TrustCenter which are =
conform to German Law and we saw that this validity model has an =
advantage (maybe this is the rational of the model). Since everyone =
seems to be unhappy with this validity model lets mention the advantage =
to the honour of the good old law.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But please don't flame me, because I'm =
sure that there are other (better?) possibilities. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The advantage is more or less of legal =
and/or organizational nature. If the CA signs a certificate, the PSE =
(e.g. your smart card with your *private* key) has to be delivered in a =
secure way to the owner. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In technical terms the certificate is =
almost valid (but not in legal terms). But the PSE hasn't handed out to =
the owner yet, - with all possibilities of abuse (I know there are ways =
to handle it in another way). But if you wait until the owner proofs =
that he received the PSE, to say the certificate is valid you avoid =
this insecure time gap. The validation is manifested by publishing the =
certificate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So I hope you see the rational of this =
validity model.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Johan</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P.s.: I wait if somone wants to bet. I =
propose we drink the beer together, - lets say at the CeBit =
2001.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7EDC.787D0640--


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10530 for <[e-mail]>; Thu, 24 Feb 2000 07:00:36 -0800 (PST)
Received: from bull.net (itinerant4.frpq.bull.fr [129.184.8.52]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA23086 for <[e-mail]>; Thu, 24 Feb 2000 16:04:58 +0100
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2000 16:04:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: German Law and OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Stefan,

Thanks for your comment. See my comments next.
 
> Denis,
> 
> > > Once such a division is made technically, it was extended to the idea
> > > that a certificate should only be valid once it is inserted in the
> > > information service database.
> >
> > I do not understand. To be "valid" a certificate does not (even)
> > have to be published. It may be given back to the user who may
> > decide to send it to whatever entity he wishes.
> 
> you're certainly right. However, the German Digital Signature Act states:
> [from http://www.iid.de/rahmen/iukdgebt.html#a3]
> 
> § 5: Issue of Certificates
> 
> (1) The certification authority shall reliably establish the identity of persons applying for a
> certificate. It shall confirm the assignment of a public signature key to an identified person
> by a signature key certificate which, together with any attribute certificates, shall be kept
> available for verification and, with the consent of the owner of the signature key, for
> retrieval at all times and for everyone over publicly available telecommunication links.
> 
> The magic statement here is "...shall be kept available for verification...
> at all times...". Therefore, a certificate implicitly is valid once it is
> made available (from the CA's repository) for verification. 

The other magic statement is: "with the consent of the owner of the
signature key". If there is no such consent, then the statement does
not apply, hence there is no publication.

"kept available for verification" does not imply any publication. It
means that the AC must keep a local copy.

Besides the wording, the question was to understand the rational of
the model. The question is still pending ...

Regards,

Denis


> Like it or
> not (I don't) - that's the way the validity model was chosen to be. E.g., I've
> been issued one of the very few certificates issued according to the law
> but since it has not been published yet it is not valid in the sense
> of the law...
> 
> The law currently is under evaluation and will be revised later this
> year. It's highly unlikely that they're going to change this validity
> model, though.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________________________
> Stefan Kelm            PGP key: "finger [e-mail]" or via key server
> DFN-PCA                                                      <[e-mail]>
> Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
> 22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10313 for <[e-mail]>; Thu, 24 Feb 2000 06:57:04 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA06560; Thu, 24 Feb 2000 10:01:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b4da0f0f961d@[128.33.238.74]>
In-Reply-To: <001801bf7ddc$5f3e0380$[e-mail]>
References: <001801bf7ddc$5f3e0380$[e-mail]>
Date: Wed, 23 Feb 2000 17:37:35 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: <[e-mail]>, <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1260717979==_ma============"

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

Anders,
	<snip>

>Not abandon, a DN would still be a DN.  Heritage is of less interest.
>The solution is a technical way to solve something that is already 
>performed using
>"local knowledge and manual settings" by a lot of current RP software.

A DN is a directory distinguished name, not just an arbitrary 
sequence of sets of attributes.

>As compatibility with existing SW is crucial, some purity will have 
>to be sacrificed.
>For radical changes like GNs it may be better to look on XML-certs 
>but that is another story.

It's not surprising that you are willing to make that tradeoff, but 
that does not constitute a rationale for doing so.  GNs are NOT a 
radical change.  2459 mandates support for several GNs already.  if 
one defined a new GN that used the same set of attributes as a DN, 
then this would be a clean solution that would allow reuse of the 
software that knows how to parse DNs, without muddying the semantics 
of DNs.

	<snip>

>As Denis nicely points out, the suggested solution allows arbitrary uses
>of DN attributes including various combinations with serialNumber and
>lets say organizationUnit.   But for the RP it looks like a singular solution
>as it just requires a call to the (anticipated) API function 
>"getQCUnmistakableIdenitity()"
>to get the optional subset of of DN that holds the unmistakable identity.
>That is what I call GENERIC SOLUTION and is what standards need.

Yes, the proposal allows arbitrary use of DN attributes, which is why 
the result is not longer a DN, and does not belong warrant being 
tagged as a DN.

	<snip>

>Unfortunately NON-STANDARD policy OIDs create much more problems than
>they solve.  I have already elaborated on that in this list.

"non-standard" policy OIDs?  This implies that there is a standard 
set, but I'm not sure where that standard set has been defined.  One 
school of thought assumes that a small set of policy OIDs will come 
into existence, hence the desire for policy qualifiers.  However, 
that is not the only model for use of policy OIDs, so I think your 
reference here is premature, and narrow.

>What is missing from the current suggestion is a Naming Domain definition.
>I can just find two variants: Either the naming domain is marked as 
>internal/CA
>and does not have to be known outside, or the CA issues certificates to
>an external naming domain like "registered Citizen of XYZ".   The 
>latter should
>require an officially registered value of some kind to be interoperable among
>competing CAs,

I think that your suggestion for a name domain definition is further 
evidence that the identifiers that you are referring to are not 
really DNs!

	<snip>

>PS Steve, do you prefer that a solution according to my and Denis lines are
>taken to PKI-FORUM rather than developed here?  I don't care where as
>long as it gets done.  DS

Is this a trick question?  Is it really an offer for you to move your 
campaign for changes to ITU and IETF standards to an industry 
consortium? How can I say no?

Steve

--============_-1260717979==_ma============
Content-Type: text/enriched; charset="us-ascii"

Anders,

	<<snip>


<excerpt>Not abandon, a DN would still be a DN.  Heritage is of less
interest.

The solution is a technical way to solve something that is already
performed using

"local knowledge and manual settings" by a lot of current RP software.

</excerpt>

A DN is a <underline>directory</underline> distinguished name, not just
an arbitrary sequence of sets of attributes. 


<excerpt>As compatibility with existing SW is crucial, some purity will
have to be sacrificed.

For radical changes like GNs it may be better to look on XML-certs but
that is another story.

</excerpt>

It's not surprising that you are willing to make that tradeoff, but
that does not constitute a rationale for doing so.  GNs are NOT a
radical change.  2459 mandates support for several GNs already.  if one
defined a new GN that used the same set of attributes as a DN, then
this would be a clean solution that would allow reuse of the software
that knows how to parse DNs, without muddying the semantics of DNs.


	<<snip>


<excerpt>As Denis nicely points out, the suggested solution allows
arbitrary uses

of DN attributes including various combinations with serialNumber and

lets say organizationUnit.   But for the RP it looks like a singular
solution

as it just requires a call to the (anticipated) API function
"getQCUnmistakableIdenitity()"

to get the optional subset of of DN that holds the unmistakable
identity.

That is what I call GENERIC SOLUTION and is what standards need.

</excerpt>

Yes, the proposal allows arbitrary use of DN attributes, which is why
the result is not longer a DN, and does not belong warrant being tagged
as a DN.


	<<snip>


<excerpt>Unfortunately NON-STANDARD policy OIDs create much more
problems than

they solve.  I have already elaborated on that in this list.

</excerpt>

"non-standard" policy OIDs?  This implies that there is a standard set,
but I'm not sure where that standard set has been defined.  One school
of thought assumes that a small set of policy OIDs will come into
existence, hence the desire for policy qualifiers.  However, that is
not the only model for use of policy OIDs, so I think your reference
here is premature, and narrow.


<excerpt>What is missing from the current suggestion is a Naming Domain
definition.

I can just find two variants: Either the naming domain is marked as
internal/CA

and does not have to be known outside, or the CA issues certificates
to

an external naming domain like "registered Citizen of XYZ".   The
latter should

require an officially registered value of some kind to be interoperable
among

competing CAs,

</excerpt>

I think that your suggestion for a name domain definition is further
evidence that the identifiers that you are referring to are not really
DNs!


	<<snip>


<excerpt>PS Steve, do you prefer that a solution according to my and
Denis lines are

taken to PKI-FORUM rather than developed here?  I don't care where as

long as it gets done.  DS

</excerpt>

Is this a trick question?  Is it really an offer for you to move your
campaign for changes to ITU and IETF standards to an industry
consortium? How can I say no?


Steve 

--============_-1260717979==_ma============--


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09248 for <[e-mail]>; Thu, 24 Feb 2000 06:26:21 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQidug21833 for <[e-mail]>; Thu, 24 Feb 2000 14:30:25 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA22094; Thu, 24 Feb 00 09:27:34 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA06041; Thu, 24 Feb 2000 09:30:23 -0500
Date: Thu, 24 Feb 2000 09:30:23 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
To: [e-mail]
Subject: Re: German Law and OCSP
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA09249

>>>>> "Stefan" == Stefan Kelm <[e-mail]> writes:

 Stefan> Denis,
 >> > Once such a division is made technically, it was extended to the
 >> idea > that a certificate should only be valid once it is inserted
 >> in the > information service database.
 >> 
 >> I do not understand. To be "valid" a certificate does not (even)
 >> have to be published. It may be given back to the user who may
 >> decide to send it to whatever entity he wishes.

 Stefan> you're certainly right. However, the German Digital Signature
 Stefan> Act states: [from http://www.iid.de/rahmen/iukdgebt.html#a3]

 Stefan> § 5: Issue of Certificates

 Stefan> (1) The certification authority shall reliably establish the
 Stefan> identity of persons applying for a certificate. It shall
 Stefan> confirm the assignment of a public signature key to an
 Stefan> identified person by a signature key certificate which,
 Stefan> together with any attribute certificates, shall be kept
 Stefan> available for verification and, with the consent of the owner
 Stefan> of the signature key, for retrieval at all times and for
 Stefan> everyone over publicly available telecommunication links.

 Stefan> The magic statement here is "...shall be kept available for
 Stefan> verification...  at all times...". Therefore, a certificate
 Stefan> implicitly is valid once it is made available (from the CA's
 Stefan> repository) for verification. Like it or not (I don't) -
 Stefan> that's the way the validity model was chosen to be. E.g.,
 Stefan> I've been issued one of the very few certificates issued
 Stefan> according to the law but since it has not been published yet
 Stefan> it is not valid in the sense of the law...

I think that may be a matter of interpretation.  The english
translation is ambiguous as to whether "at all times and for everyone" 
applies to retrieval only, or also to verification.  The original
makes it clear the latter is correct.

One way of reading that is "any person should be able to verify the
validity of the certificate; if any communication channels are needed
for this, public one should suffice".  The standard algorithm of
checking the CA signature and the CRL is an example of such a process, 
assuming that the current CRL is available over public communications
channels.  

	paul


Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07690 for <[e-mail]>; Thu, 24 Feb 2000 05:45:46 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id OAA16011; Thu, 24 Feb 2000 14:47:31 +0100 (MET)
Date: Thu, 24 Feb 2000 14:47:31 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: German Law and OCSP
Cc: [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: ISO-8859-1

Denis,

> > Once such a division is made technically, it was extended to the idea
> > that a certificate should only be valid once it is inserted in the
> > information service database.
>
> I do not understand. To be "valid" a certificate does not (even)
> have to be published. It may be given back to the user who may
> decide to send it to whatever entity he wishes.

you're certainly right. However, the German Digital Signature Act states:
[from http://www.iid.de/rahmen/iukdgebt.html#a3]

§ 5: Issue of Certificates

(1) The certification authority shall reliably establish the identity of persons applying for a
certificate. It shall confirm the assignment of a public signature key to an identified person
by a signature key certificate which, together with any attribute certificates, shall be kept
available for verification and, with the consent of the owner of the signature key, for
retrieval at all times and for everyone over publicly available telecommunication links.

The magic statement here is "...shall be kept available for verification...
at all times...". Therefore, a certificate implicitly is valid once it is
made available (from the CA's repository) for verification. Like it or
not (I don't) - that's the way the validity model was chosen to be. E.g., I've
been issued one of the very few certificates issued according to the law
but since it has not been published yet it is not valid in the sense
of the law...

The law currently is under evaluation and will be revised later this
year. It's highly unlikely that they're going to change this validity
model, though.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA                                                      <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: [phone] / Fax: -2241


Received: from mail-int.cubis.de (maildt.cubis.de [212.185.174.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07270 for <[e-mail]>; Thu, 24 Feb 2000 05:38:25 -0800 (PST)
Received: from ex-mail.cubis.de (ex-mail.cubis.de [10.31.4.65]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id OAA06828; Thu, 24 Feb 2000 14:42:20 +0100 (MET)
Received: by ex-mail.cubis.de with Internet Mail Service (5.5.2650.21) id <1PRNDXMK>; Thu, 24 Feb 2000 14:40:15 +0100
Message-ID: <[e-mail]>
From: "Hesse, Johan" <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: German Law and OCSP
Date: Thu, 24 Feb 2000 14:37:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7ECC.ADF06180"

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

------_=_NextPart_001_01BF7ECC.ADF06180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello out there!

It seems that there are a lot of confusions regarding some terms in the
German Law.
As considered there are two distinct entities. One for issuing =
certificates
and one for revoking certificates. The revocation is maintained by the
directory service (DIR, Andreas Berger described it with "information
service"). In the moment the issuing entity signs a certificate you may =
be
attempted to say its valid, but in the sense of German Law a valid
certificate has to be published. Published in this coherence means that =
the
certificate is either *checkable* (you can only get status information) =
or
*retrievable* (you can get status information and the whole =
certificate).
Both status have to be maintained by the DIR.

I think the confusion springs from legal terms. In the above mentioned
example the technical term of *valid* for a certificate would be the =
moment
of the signing with the signing key. The legal term assumes the =
publishing
of the certificate.

Another misunderstanding seems to be the role of the CRL in German Law. =


Antonio Lioy wrote (28.01.2000) "... the only legally binding way to =
prove
that a cert was not valid at a certain date is to provide a CRL (or a
CSL!!!) that includes it." The German Law requires only the =
*checkability*
of the status of a certificate for anybody to any time (=A74 SigG). The
interoperability schemes (SigI A5) propose OCSP. The status =
*suspension*
isn't allowed according to the German Law, in comparision with Italian =
law
which requires a CRL (Art. 29 par. 3) and the possibility of suspension
(Art. 33).

   Best regards,  =20
                        Johan Hesse

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : [phone]
> Fax   : [phone]
> mailto:[e-mail]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7ECC.ADF06180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: German Law and OCSP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello out there!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It seems that there are a lot of =
confusions regarding some terms in the German Law.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As considered there are two distinct =
entities. One for issuing certificates and one for revoking =
certificates. The revocation is maintained by the directory service =
(DIR, Andreas Berger described it with &quot;information =
service&quot;). In the moment the issuing entity signs a certificate =
you may be attempted to say its valid, but in the sense of German Law a =
valid certificate has to be published. Published in this coherence =
means that the certificate is either *checkable* (you can only get =
status information) or *retrievable* (you can get status information =
and the whole certificate). Both status have to be maintained by the =
DIR.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think the confusion springs from =
legal terms. In the above mentioned example the technical term of =
*valid* for a certificate would be the moment of the signing with the =
signing key. The legal term assumes the publishing of the =
certificate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another misunderstanding seems to be =
the role of the CRL in German Law. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Antonio Lioy wrote (28.01.2000) =
&quot;... the only legally binding way to prove that a cert was not =
valid at a certain date is to provide a CRL (or a CSL!!!) that includes =
it.&quot; The German Law requires only the *checkability* of the status =
of a certificate for anybody to any time (=A74 SigG). The =
interoperability schemes (SigI A5) propose OCSP. The status =
*suspension* isn't allowed according to the German Law, in comparision =
with Italian law which requires a CRL (Art. 29 par. 3) and the =
possibility of suspension (Art. 33).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Best regards,&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Johan Hesse</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7ECC.ADF06180--


Received: from menelao.polito.it (menelao.polito.it [130.192.3.30]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA25889 for <[e-mail]>; Thu, 24 Feb 2000 00:51:21 -0800 (PST)
Received: (qmail 7649 invoked from network); 24 Feb 2000 08:55:33 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by menelao.polito.it with SMTP; 24 Feb 2000 08:55:33 -0000
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2000 09:55:23 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Straw Poll: SerialNumber definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bengt Ohlsson wrote:
> 
> Stefan,
> 
> I think there is an even simpler solution to the problem
> by using the SubjectAltName extension. Just take those
> RDNs that are required to make the name unique and
> use those RDNs as a directoryName entry in the
> SubjectAltName extension. E.g. if the serialNumber
> attribute is unique by itself, then the SubjectAltName
> entry will only contain the serialNumber. This also allows
> for a QC to contain different forms of unique names for
> the same subject.
> 
> This will not affect any existing applications, since no
> new attributes are instroduced. New applications that
> will use QC can use the SubjectAltName extension to
> find a name that is usable for the application.

I support this position.

We have already used the subjectAltName extension and we are
quite satisfied with it. In fact we can have more than one
of it, to insert into the certificate a variety of SN or
unique identifiers.
For example, we use it to insert our unique University ID
but a second extension could be added for standard Italian
national personal code, or for the case where the same
individual belongs to two different organizations.

Each subjectAltName is distinguished by a unique OID and
hence each application can look for the one that it is able
to deal with.

This goes in the line of having just one certificate for
person, instead of forcing people to have multiple
certificates for multiple applications.

Antonio Lioy


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25253 for <[e-mail]>; Thu, 24 Feb 2000 00:28:50 -0800 (PST)
Received: from mega (t1o69p60.telia.com [62.20.144.60]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA27223; Thu, 24 Feb 2000 09:36:20 +0100
Message-ID: <002301bf7ea9$9afda470$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:29:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA25254

David,
Although I like the simplicity of the scheme it does IMO limit the ways you
can express Unmistakable Identity (UI).

I am not sure (since my X500 is rather sluggish) but it seems that you may have to move
around RDNs in order to create what you want. Do we want that?  

Let's say
DN = CN + [OU + SN]        ;Organization Unit and Serial Number
DN = CN + [SN] + OU       ; Only serial number (Swedish EID)
DN = [CN+SN] + OU        ; Probably name disambiguer usage

The [] indicates UI.   Is that compatible with this single boolean of yours?
BTW, can't an e-mail address also serve as a UI?

Conclusion: Denis' orginal position-oriented BITSTRING is more universal and
can even be applied to private RDNs.

Anders

-----Original Message-----
From: David P. Kemp <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Wednesday, February 23, 2000 22:10
Subject: Re: Straw Poll: SerialNumber definition


>
>> From: Denis Pinkas <[e-mail]>
>> 
>> The solution to use the certPolicy OID proposed by Steve would not
>> work for an automated processing.
>> The solution proposed by Stefan would work, but I have something
>> simpler (but less flexible) that could possibly work.
>
>Simpler is better. :-)
>
>
>> The idea is that the *relative* placement of the UI in the DN chain
>> indicates to what it applies. In other words it serves like a
>> delimiter. Everything on the left of the delimiter has to be used to
>> make the name unique and permanent, for the given CA. If it comes
>> first, then it is self-sufficient by itself (e.g. it could be a
>> social security number or an employee number). In the following
>> example, it would only apply to G, I and S but not to O.
>> 
>> G=; I=; S=; UI= ; O=;
>> 
>> What do you think ?
>
>
>This solution presupposes that X.509 DNs do not have a one-to-one
>correspondence with the directory tree.  The last time a similar scheme
>came up in this thread, it was remarked that there is/should-be a
>direct mapping between the entire X.509 Distinguished Name and the
>directory. The two certs:
>
>  (1)   CN=; SN=; OU=; O=; C=;
>  (2)   CN= + SN=; OU=; O=; C=;
>
>would be stored as follows in the DIT:
>
>          (1)                       (2)
>
>           C                         C
>          / \                       / \
>         O   O                     O   O
>        / |  | \                  / |  | \
>       OU                        OU
>      /  \                      /  \
>     SN                      SN+CN
>     |
>     CN
>
>The problem with cert (1) is that it creates an additional layer
>in the directory where each SN node has only a single child.  The
>problem with cert (2) is that it does not specify whether the value
>of CN is a significant part of the subject's identity or just a
>human-readable comment.
>
>If a "delimiter" UI attribute were defined, cert (1) could have five
>single-AT&V RDNs but still be stored in a four-level directory structure:
>
>                              (1)
>
>                               C
>                              / \
>                             O   O
>                            / |  | \
>                           OU
>                          /  \
>           delimiter ->  UI
> (remainder of DN is
> just human-readable
> information)
> 
>
>Stefan previously suggested five alternatives for the static
>identifier, each of which had advantages and disadvantages.  At that
>time the creation of a new RDN attribute was deemed less desirable than
>using the existing SN attribute.  I don't believe the situation leading
>to that decision has changed.
>
>However, Stefan's suggestion to use a dnIdentityMask contained in
>the QC Statements extension can be simplified along the lines suggested
>by Denis and Peter Sylvester without requiring a new RDN attribute.
>All that is needed is a boolean signal indicating if the SN attribute
>is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
>additional AT&Vs in the current RDN are treated as comments, not part
>of the "DN Identity" or directory structure.  If absent or FALSE, the
>SN attribute is not treated as a delimiter.
>
>The form of the signal is immaterial. I believe it can be contained
>implicitly within Cert Policies OIDs, Anders believes an explicit
>signal is necessary; both views can be accommodated by defining an
>optional boolean field somewhere within the QC Statements extension.
>
>As an example, one could replace Stefan's
>
>>       SemanticsInformation ::= SEQUENCE {
>>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>>           nameRegistrationAuthorities NameRegistrationAuthorities
>>                                                           OPTIONAL
>>           dnIdentityMask              DnIdentityMask   OPTIONAL}
>>
>>           DnIdentityMask ::= BIT STRING {
>>                countryName             (0),
>>                commonName              (1),
>>                surname                 (2),
>>                givenName               (3),
>>                pseudonym               (4),
>>                serialNumber            (5),
>>                organizationName        (6),
>>                organizationalUnitName  (7),
>>                stateOrProvinceName     (8),
>>                localityName            (9),
>>                postalAddress          (10)}
>
>
>with
>
>>       SemanticsInformation ::= SEQUENCE {
>>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>>           nameRegistrationAuthorities NameRegistrationAuthorities
>>                                                           OPTIONAL
>>           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
>The advantage of using a "delimiter signal" or "static UID signal" with
>SN instead of defining a new RDN attribute is the same as before - it
>maximizes interoperability with existing certificates and
>applications.  Many applications are getting along quite well using
>multi-value RDNs and application-defined treatment of "affiliation
>numbers".  These applications will continue to work with certs
>containing a non-critical QC Statements extension; they would be broken
>by a new RDN attribute.
>
>Stefan and the WG chairs can decide if it is appropriate to be munging
>syntax during Last Call :-).  If we can't reach quick agreement, I
>believe definition of a static UID signal should be deferred to the
>next QC iteration and the current draft should proceed to RFC.



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25015 for <[e-mail]>; Thu, 24 Feb 2000 00:24:46 -0800 (PST)
Received: from mega (t1o69p60.telia.com [62.20.144.60]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA26928; Thu, 24 Feb 2000 09:32:18 +0100
Message-ID: <002201bf7ea9$0a858ac0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Bengt Ohlsson" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:25:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA25016

Bengt,

<snip>

>This will not affect any existing applications, since no
>new attributes are instroduced. New applications that
>will use QC can use the SubjectAltName extension to
>find a name that is usable for the application.


The idea is (in my opinion at least) that existing aplication should continue to work
as this must be an uncritical extension.  But that new applications should see this
extension as the signal: "Plug'nPlay Certificate".   That requires though that the
NAMING DOMAIN issue is also covered by this extension.

Anders



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24684 for <[e-mail]>; Thu, 24 Feb 2000 00:06:42 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <FNY37RAP>; Thu, 24 Feb 2000 09:10:14 +0100
Message-ID: <[e-mail]>
From: Bengt Ohlsson <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:10:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Stefan,

I think there is an even simpler solution to the problem
by using the SubjectAltName extension. Just take those
RDNs that are required to make the name unique and
use those RDNs as a directoryName entry in the
SubjectAltName extension. E.g. if the serialNumber 
attribute is unique by itself, then the SubjectAltName
entry will only contain the serialNumber. This also allows
for a QC to contain different forms of unique names for
the same subject.

This will not affect any existing applications, since no
new attributes are instroduced. New applications that
will use QC can use the SubjectAltName extension to
find a name that is usable for the application.

/Bengt


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: den 24 februari 2000 01:16
To: 'David P. Kemp'; [e-mail]; [e-mail]
Subject: RE: Straw Poll: SerialNumber definition


David,

Your proposal seams like a nice, simple and reasonable solution.
Lets see if it can gain support from the critical eyes on this list. If so
then I can live with it.

-----
Caution Note to those participating in this thread: Please avoid cross
postings to other lists (such as SEIS and EL-SIGN) since it gets rather
nasty when people make "reply to all" on the postings. I have already got
complaints from people on the EL-SIGN list. So when replying to these
postings, please remove other lists from the recipient header.

/Stefan

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
>
> > From: Denis Pinkas <[e-mail]>
> >
> > The solution to use the certPolicy OID proposed by Steve would not
> > work for an automated processing.
> > The solution proposed by Stefan would work, but I have something
> > simpler (but less flexible) that could possibly work.
>
> Simpler is better. :-)
>
>
> > The idea is that the *relative* placement of the UI in the DN chain
> > indicates to what it applies. In other words it serves like a
> > delimiter. Everything on the left of the delimiter has to be used to
> > make the name unique and permanent, for the given CA. If it comes
> > first, then it is self-sufficient by itself (e.g. it could be a
> > social security number or an employee number). In the following
> > example, it would only apply to G, I and S but not to O.
> >
> > G=; I=; S=; UI= ; O=;
> >
> > What do you think ?
>
>
> This solution presupposes that X.509 DNs do not have a one-to-one
> correspondence with the directory tree.  The last time a
> similar scheme
> came up in this thread, it was remarked that there is/should-be a
> direct mapping between the entire X.509 Distinguished Name and the
> directory. The two certs:
>
>   (1)   CN=; SN=; OU=; O=; C=;
>   (2)   CN= + SN=; OU=; O=; C=;
>
> would be stored as follows in the DIT:
>
>           (1)                       (2)
>
>            C                         C
>           / \                       / \
>          O   O                     O   O
>         / |  | \                  / |  | \
>        OU                        OU
>       /  \                      /  \
>      SN                      SN+CN
>      |
>      CN
>
> The problem with cert (1) is that it creates an additional layer
> in the directory where each SN node has only a single child.  The
> problem with cert (2) is that it does not specify whether the value
> of CN is a significant part of the subject's identity or just a
> human-readable comment.
>
> If a "delimiter" UI attribute were defined, cert (1) could have five
> single-AT&V RDNs but still be stored in a four-level
> directory structure:
>
>                               (1)
>
>                                C
>                               / \
>                              O   O
>                             / |  | \
>                            OU
>                           /  \
>            delimiter ->  UI
>  (remainder of DN is
>  just human-readable
>  information)
>
>
> Stefan previously suggested five alternatives for the static
> identifier, each of which had advantages and disadvantages.  At that
> time the creation of a new RDN attribute was deemed less
> desirable than
> using the existing SN attribute.  I don't believe the
> situation leading
> to that decision has changed.
>
> However, Stefan's suggestion to use a dnIdentityMask contained in
> the QC Statements extension can be simplified along the lines
> suggested
> by Denis and Peter Sylvester without requiring a new RDN attribute.
> All that is needed is a boolean signal indicating if the SN attribute
> is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
> additional AT&Vs in the current RDN are treated as comments, not part
> of the "DN Identity" or directory structure.  If absent or FALSE, the
> SN attribute is not treated as a delimiter.
>
> The form of the signal is immaterial. I believe it can be contained
> implicitly within Cert Policies OIDs, Anders believes an explicit
> signal is necessary; both views can be accommodated by defining an
> optional boolean field somewhere within the QC Statements extension.
>
> As an example, one could replace Stefan's
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
>
>
> with
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
> The advantage of using a "delimiter signal" or "static UID
> signal" with
> SN instead of defining a new RDN attribute is the same as before - it
> maximizes interoperability with existing certificates and
> applications.  Many applications are getting along quite well using
> multi-value RDNs and application-defined treatment of "affiliation
> numbers".  These applications will continue to work with certs
> containing a non-critical QC Statements extension; they would
> be broken
> by a new RDN attribute.
>
> Stefan and the WG chairs can decide if it is appropriate to be munging
> syntax during Last Call :-).  If we can't reach quick agreement, I
> believe definition of a static UID signal should be deferred to the
> next QC iteration and the current draft should proceed to RFC.
>


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10633 for <[e-mail]>; Wed, 23 Feb 2000 18:32:48 -0800 (PST)
Received: from ctex01.us.cybertrust.com (ctex01.us.cybertrust.com [192.233.30.4]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id VAA08815 for <[e-mail]>; Wed, 23 Feb 2000 21:36:55 -0500 (EST)
Received: by ctex01.us.cybertrust.com with Internet Mail Service (5.5.2650.21) id <DF6Z0P29>; Wed, 23 Feb 2000 21:37:26 -0500
Message-ID: <[e-mail]>
From: "Dulude, Bob" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Wed, 23 Feb 2000 21:37:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04061 for <[e-mail]>; Wed, 23 Feb 2000 15:11:49 -0800 (PST)
Received: from bestlaptop (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA00641; Thu, 24 Feb 2000 00:15:58 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 01:16:03 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

David,

Your proposal seams like a nice, simple and reasonable solution.
Lets see if it can gain support from the critical eyes on this list. If so
then I can live with it.

-----
Caution Note to those participating in this thread: Please avoid cross
postings to other lists (such as SEIS and EL-SIGN) since it gets rather
nasty when people make "reply to all" on the postings. I have already got
complaints from people on the EL-SIGN list. So when replying to these
postings, please remove other lists from the recipient header.

/Stefan

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
>
> > From: Denis Pinkas <[e-mail]>
> >
> > The solution to use the certPolicy OID proposed by Steve would not
> > work for an automated processing.
> > The solution proposed by Stefan would work, but I have something
> > simpler (but less flexible) that could possibly work.
>
> Simpler is better. :-)
>
>
> > The idea is that the *relative* placement of the UI in the DN chain
> > indicates to what it applies. In other words it serves like a
> > delimiter. Everything on the left of the delimiter has to be used to
> > make the name unique and permanent, for the given CA. If it comes
> > first, then it is self-sufficient by itself (e.g. it could be a
> > social security number or an employee number). In the following
> > example, it would only apply to G, I and S but not to O.
> >
> > G=; I=; S=; UI= ; O=;
> >
> > What do you think ?
>
>
> This solution presupposes that X.509 DNs do not have a one-to-one
> correspondence with the directory tree.  The last time a
> similar scheme
> came up in this thread, it was remarked that there is/should-be a
> direct mapping between the entire X.509 Distinguished Name and the
> directory. The two certs:
>
>   (1)   CN=; SN=; OU=; O=; C=;
>   (2)   CN= + SN=; OU=; O=; C=;
>
> would be stored as follows in the DIT:
>
>           (1)                       (2)
>
>            C                         C
>           / \                       / \
>          O   O                     O   O
>         / |  | \                  / |  | \
>        OU                        OU
>       /  \                      /  \
>      SN                      SN+CN
>      |
>      CN
>
> The problem with cert (1) is that it creates an additional layer
> in the directory where each SN node has only a single child.  The
> problem with cert (2) is that it does not specify whether the value
> of CN is a significant part of the subject's identity or just a
> human-readable comment.
>
> If a "delimiter" UI attribute were defined, cert (1) could have five
> single-AT&V RDNs but still be stored in a four-level
> directory structure:
>
>                               (1)
>
>                                C
>                               / \
>                              O   O
>                             / |  | \
>                            OU
>                           /  \
>            delimiter ->  UI
>  (remainder of DN is
>  just human-readable
>  information)
>
>
> Stefan previously suggested five alternatives for the static
> identifier, each of which had advantages and disadvantages.  At that
> time the creation of a new RDN attribute was deemed less
> desirable than
> using the existing SN attribute.  I don't believe the
> situation leading
> to that decision has changed.
>
> However, Stefan's suggestion to use a dnIdentityMask contained in
> the QC Statements extension can be simplified along the lines
> suggested
> by Denis and Peter Sylvester without requiring a new RDN attribute.
> All that is needed is a boolean signal indicating if the SN attribute
> is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
> additional AT&Vs in the current RDN are treated as comments, not part
> of the "DN Identity" or directory structure.  If absent or FALSE, the
> SN attribute is not treated as a delimiter.
>
> The form of the signal is immaterial. I believe it can be contained
> implicitly within Cert Policies OIDs, Anders believes an explicit
> signal is necessary; both views can be accommodated by defining an
> optional boolean field somewhere within the QC Statements extension.
>
> As an example, one could replace Stefan's
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
>
>
> with
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
> The advantage of using a "delimiter signal" or "static UID
> signal" with
> SN instead of defining a new RDN attribute is the same as before - it
> maximizes interoperability with existing certificates and
> applications.  Many applications are getting along quite well using
> multi-value RDNs and application-defined treatment of "affiliation
> numbers".  These applications will continue to work with certs
> containing a non-critical QC Statements extension; they would
> be broken
> by a new RDN attribute.
>
> Stefan and the WG chairs can decide if it is appropriate to be munging
> syntax during Last Call :-).  If we can't reach quick agreement, I
> believe definition of a static UID signal should be deferred to the
> next QC iteration and the current draft should proceed to RFC.
>



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03477 for <[e-mail]>; Wed, 23 Feb 2000 14:35:47 -0800 (PST)
Received: from bestlaptop (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA32708; Wed, 23 Feb 2000 23:39:53 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 19:22:05 +0100
Message-ID: <000001bf7e4f$54ff5900$6d6fa8c0@bestlaptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Denis,

Let me first state that my solution was not a proposal. I don't know yet if
I like it myself. It was just a solution thrown to the floor for open
consideration. Personally I'm not yet convinced that we have a problem that
should be fixed in the first place.

But anyway, I don't like the solution you you present here by one big
reason, it introduces a new nonstandard attribute in the subject field. That
has been considered before and the principial standpoint is that it should
be avoided.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, February 23, 2000 4:19 PM
> To: [e-mail]; [e-mail]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
> Since the last call period is now open, let us attempt to
> (hopefully) solve this issue within that period.
>
> The solution to use the certPolicy OID proposed by Steve would not
> work for an automated processing.
> The solution proposed by Stefan would work, but I have something
> simpler (but less flexible) that could possibly work.
>
> Let is take a look at an old INFORMATIONAL RFC, i.e. RFC 1685
> issused in August 1994. Its name is: Writing X.400 O/R Names.
>
> Basically this document *recommends* a sequence for writing
> distinguished names for human beings which is:
>
> G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;
>
> with:
>
>     Given Name                             Given name        G
>     Initial                                Initials          I
>     Surname                                Surname           S
>     Generation Qualifier                   Generation        Q
>     Common Name                            Common Name       CN
>     Organization                           Organization      O
>     Organizational Unit 1                  Org.Unit.1        OU1
>     Organizational Unit 2                  Org.Unit.2        OU2
>     Organizational Unit 3                  Org.Unit.3        OU3
>     Organizational Unit 4                  Org.Unit.4        OU4
>     Private Management Domain Name         PRMD              P
>     Administration Management Domain Name  ADMD              A
>     Country                                Country           C
>
> Suppose that now we introduce the new atribute called
> UniqueIdentifier (UI), instead of SerialNumber which is a little bit
> confusing.
>
> The idea is that the *relative* placement of the UI in the DN chain
> indicates to what it applies. In other words it serves like a
> delimiter. Everything on the left of the delimiter has to be used to
> make the name unique and permanent, for the given CA. If it comes
> first, then it is self-sufficient by itself (e.g. it could be a
> social security number or an employee number). In the following
> example, it would only apply to G, I and S but not to O.
>
> G=; I=; S=; UI= ; O=;
>
> What do you think ?
>
> Denis
>
>
> > Guys,
> >
> > I may have a nice solution to this debate.
> >
> > May I first draw your attention once again to the fact that
> the solution in
> > the qcStatement extension almost have what you ask for in
> the first place.
> >
> > What we have is a predefined statement in QC 03 saying:
> >
> >    3.2.5.1 Predefined Statements
> >
> >    This profile includes one predefined object identifier (id-qcs-
> >    pkixQCSyntax-v1), identifying conformance with syntax
> and semantics
> >    defined in this profile. This Qualified Certificate profile is
> >    referred to as version 1.
> >
> >       qcStatement-1 QC-STATEMENT ::= { SemanticsInformation
> IDENTIFIED
> >           BY id-qcs-pkixQCSyntax-v1 }
> >       --  This statement identifies conformance with syntax and
> >       --  semantics defined in this Qualified Certificate profile
> >       --  (Version 1). The SemanticsInformation may
> optionally contain
> >       --  additional semantics information as specified.
> >
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL }
> >           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
> >            WITH COMPONENTS {...,
> nameRegistrationAuthorities PRESENT})
> >
> >       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
> >           GeneralName
> >
> > This is a predefined statement dedicated to include
> information that would
> > clarify the actual content in the DN attributes.
> > Lets say that we added another optional data element
> "dnIdentityMask" in the
> > samanticsInformation:
> >
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
> >
> > The defined meaning of dnIdentitymask would then be to
> specify the minimum
> > set of attributes needed to obtain a unique identity of the
> subject, needed
> > to identify the subject among all subjects handled by the CA.
> >
> > The good side of this solution is that it can be used
> without any need to
> > define a new OID, since the attribute semantics OID is optional.
> >
> > This solution could in a nice way satisfy all needs raised
> in the discussion
> > without breaking any current practice or stretch any
> intended definitions or
> > structures.
> >
> > I guess that this could be considered as a minor
> adjustments to be included
> > without requiring a new last call period.
> >
> > Thoughts, comments?
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: Anders Rundgren [mailto:[e-mail]]
> > > Sent: Wednesday, February 23, 2000 10:00 AM
> > > To: Denis Pinkas; Stephen Kent
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: Straw Poll: SerialNumber definition
> > >
> > >
> > > Steve,
> > >
> > > <snip>
> > > >I'm opposed to adding a notion of selective marking of RDNs to
> > > >indicate which ones, in concert, really qualify as a DN,
> remembering
> > > >the definition of a DN.  This was the subject of a
> private message
> > > >exchange between Anders and me last week, so I'm happy
> to share my
> > > >thoughts on this topic.
> > > >
> > > >The notion underlying this proposal seems to be that DNs are
> > > >convenient ways to express human readable names, but
> that in using
> > > >them we should abandon all notions of the DIT context from
> > > which they
> > > >emanated.
> > >
> > > Not abandon, a DN would still be a DN.  Heritage is of
> less interest.
> > > The solution is a technical way to solve something that is
> > > already performed using
> > > "local knowledge and manual settings" by a lot of current
> RP software.
> > >
> > > > A purer way to address this need would be to define a new
> > > >name type under general names (we have a couple of
> options for this
> > > >in GNs), but this would not be backward compatible with
> > > existing apps
> > > >that already have some ability to parse DNs, but not all forms of
> > > >GNs, much less a new form.
> > >
> > > As compatibility with existing SW is crucial, some purity
> > > will have to be sacrificed.
> > > For radical changes like GNs it may be better to look on
> > > XML-certs but that is another story.
> > >
> > > <snip>
> > >
> > > >I think a better approach to the base problem that motivated this
> > > >debate is to use an extension that claims to be a unique
> ID for the
> > > >subject, relative to the Issuer.  But, we already have
> such a value,
> > > >in the form of the SubjectUniqueID, if we really want
> this feature!
> > >
> > > As Denis nicely points out, the suggested solution allows
> > > arbitrary uses
> > > of DN attributes including various combinations with
> serialNumber and
> > > lets say organizationUnit.   But for the RP it looks like a
> > > singular solution
> > > as it just requires a call to the (anticipated) API function
> > > "getQCUnmistakableIdenitity()"
> > > to get the optional subset of of DN that holds the
> > > unmistakable identity.
> > > That is what I call GENERIC SOLUTION and is what standards need.
> > >
> > > SubjectUniqueID is a SPECIAL CASE of no general interest.
> > >
> > > <snip>
> > >
> > > >certs contain subject DNs that differ in other attributes?  Well,
> > > >since all the other proposals for selective RDN use require some
> > > >means of signalling RP software, why not use a cert policy
> > > OID?  It's
> > > >just as valid a means of signalling this non-standard
> > > interpretation,
> > > >for the set of RP software that will need to make use of
> this fact.
> > >
> > > Unfortunately NON-STANDARD policy OIDs create much more
> problems than
> > > they solve.  I have already elaborated on that in this list.
> > >
> > > What is missing from the current suggestion is a Naming
> > > Domain definition.
> > > I can just find two variants: Either the naming domain is
> > > marked as internal/CA
> > > and does not have to be known outside, or the CA issues
> > > certificates to
> > > an external naming domain like "registered Citizen of XYZ".
> > > The latter should
> > > require an officially registered value of some kind to be
> > > interoperable among
> > > competing CAs,
> > >
> > > Conclusion: the maintenance and setup of QC RP SW  can be
> > > really greatly simplified!
> > >
> > > OK, it does not solve the actual meaning of OU, CN, and SN
> > > etc. but somewhere you
> > > have to stop!
> > >
> > > Anders
> > >
> > > PS Steve, do you prefer that a solution according to my and
> > > Denis lines are
> > > taken to PKI-FORUM rather than developed here?  I don't
> care where as
> > > long as it gets done.  DS
> > >
> > >
>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02740 for <[e-mail]>; Wed, 23 Feb 2000 14:01:41 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA05736; Wed, 23 Feb 2000 17:06:02 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA05732; Wed, 23 Feb 2000 17:06:01 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id RAA07367; Wed, 23 Feb 2000 17:05:52 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id RAA00875; Wed, 23 Feb 2000 17:02:55 -0500 (EST)
Message-Id: <[e-mail]>
Date: Wed, 23 Feb 2000 17:02:55 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
To: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Nnff4TD6hrkr7Ezu8EONng==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Denis Pinkas <[e-mail]>
> 
> The solution to use the certPolicy OID proposed by Steve would not
> work for an automated processing.
> The solution proposed by Stefan would work, but I have something
> simpler (but less flexible) that could possibly work.

Simpler is better. :-)


> The idea is that the *relative* placement of the UI in the DN chain
> indicates to what it applies. In other words it serves like a
> delimiter. Everything on the left of the delimiter has to be used to
> make the name unique and permanent, for the given CA. If it comes
> first, then it is self-sufficient by itself (e.g. it could be a
> social security number or an employee number). In the following
> example, it would only apply to G, I and S but not to O.
> 
> G=; I=; S=; UI= ; O=;
> 
> What do you think ?


This solution presupposes that X.509 DNs do not have a one-to-one
correspondence with the directory tree.  The last time a similar scheme
came up in this thread, it was remarked that there is/should-be a
direct mapping between the entire X.509 Distinguished Name and the
directory. The two certs:

  (1)   CN=; SN=; OU=; O=; C=;
  (2)   CN= + SN=; OU=; O=; C=;

would be stored as follows in the DIT:

          (1)                       (2)

           C                         C
          / \                       / \
         O   O                     O   O
        / |  | \                  / |  | \
       OU                        OU
      /  \                      /  \
     SN                      SN+CN
     |
     CN

The problem with cert (1) is that it creates an additional layer
in the directory where each SN node has only a single child.  The
problem with cert (2) is that it does not specify whether the value
of CN is a significant part of the subject's identity or just a
human-readable comment.

If a "delimiter" UI attribute were defined, cert (1) could have five
single-AT&V RDNs but still be stored in a four-level directory structure:

                              (1)

                               C
                              / \
                             O   O
                            / |  | \
                           OU
                          /  \
           delimiter ->  UI
 (remainder of DN is
 just human-readable
 information)
 

Stefan previously suggested five alternatives for the static
identifier, each of which had advantages and disadvantages.  At that
time the creation of a new RDN attribute was deemed less desirable than
using the existing SN attribute.  I don't believe the situation leading
to that decision has changed.

However, Stefan's suggestion to use a dnIdentityMask contained in
the QC Statements extension can be simplified along the lines suggested
by Denis and Peter Sylvester without requiring a new RDN attribute.
All that is needed is a boolean signal indicating if the SN attribute
is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
additional AT&Vs in the current RDN are treated as comments, not part
of the "DN Identity" or directory structure.  If absent or FALSE, the
SN attribute is not treated as a delimiter.

The form of the signal is immaterial. I believe it can be contained
implicitly within Cert Policies OIDs, Anders believes an explicit
signal is necessary; both views can be accommodated by defining an
optional boolean field somewhere within the QC Statements extension.

As an example, one could replace Stefan's

>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           dnIdentityMask              DnIdentityMask   OPTIONAL}
>
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}


with

>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           snIsDelimiter              BOOLEAN DEFAULT FALSE}



The advantage of using a "delimiter signal" or "static UID signal" with
SN instead of defining a new RDN attribute is the same as before - it
maximizes interoperability with existing certificates and
applications.  Many applications are getting along quite well using
multi-value RDNs and application-defined treatment of "affiliation
numbers".  These applications will continue to work with certs
containing a non-critical QC Statements extension; they would be broken
by a new RDN attribute.

Stefan and the WG chairs can decide if it is appropriate to be munging
syntax during Last Call :-).  If we can't reach quick agreement, I
believe definition of a static UID signal should be deferred to the
next QC iteration and the current draft should proceed to RFC.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00571 for <[e-mail]>; Wed, 23 Feb 2000 11:22:28 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA11447; Wed, 23 Feb 2000 20:26:11 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 23 Feb 2000 20:26:11 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA22088; Wed, 23 Feb 2000 20:26:10 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA01155; Wed, 23 Feb 2000 20:26:09 +0100 (MET)
Date: Wed, 23 Feb 2000 20:26:09 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Straw Poll: SerialNumber definition
Cc: [e-mail], [e-mail]

> 
> Peter,
> 
> Your solution is of course possible.  That it is easier to explain is one thing.  To
> implement them in SW is fairly equivalent.
> 
> How about a SET of RDN OIDs instead of this BITSTRING?

That won't work, you can one OU that is part of the unique element and another
that is part of changable part. You could do a bitstring to indicate
which position in the sequence is fixed or not for EACH naming scheme. 
(I am not sayin that I like such a complex solution.)


> 
> 
> >Why the hell do we have object identifiers in RDNs, and not
> >numbers? 
BTW: I have been living in France for so many years now that I have
forgotten that a German person normally doesn't use such DIRECT comments. 
in fact it is one French way to say: Please, you might consider to read this. :-)

Regards and have fun.


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29505 for <[e-mail]>; Wed, 23 Feb 2000 10:33:50 -0800 (PST)
Received: from mega (t2o69p110.telia.com [62.20.144.230]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id TAA07635; Wed, 23 Feb 2000 19:41:12 +0100
Message-ID: <00c601bf7e34$f03d94b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 19:34:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA29506

Peter,

Your solution is of course possible.  That it is easier to explain is one thing.  To
implement them in SW is fairly equivalent.

How about a SET of RDN OIDs instead of this BITSTRING?

The reason I prefer the separate approach is that this QC Statement could
contain a block of things that would help the mecanic
interpretation of certs.  Like naming domain.   Yes, the existence
of this QC Statement could signify: "Plug'nPlay Certificate".

Anders


>Why the hell do we have object identifiers in RDNs, and not
>numbers? 
>
>> 
>>           DnIdentityMask ::= BIT STRING {
>>                countryName             (0),
>>                commonName              (1),
>>                surname                 (2),
>>                givenName               (3),
>>                pseudonym               (4),
>>                serialNumber            (5),
>>                organizationName        (6),
>>                organizationalUnitName  (7),
>>                stateOrProvinceName     (8),
>>                localityName            (9),
>>                postalAddress          (10)}
>
>It seems that the most simple solution is to add a new attribute
>'the at-sign', or the stop sign. The attribute has no possible
>values, its placement inside the RDN SEQUENCE indicates that everything
>before defines the unique entity. 
>
<snip>



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29064 for <[e-mail]>; Wed, 23 Feb 2000 10:14:29 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA10519; Wed, 23 Feb 2000 19:18:19 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 23 Feb 2000 19:18:18 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA21770; Wed, 23 Feb 2000 19:18:12 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA01136; Wed, 23 Feb 2000 19:18:11 +0100 (MET)
Date: Wed, 23 Feb 2000 19:18:11 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Straw Poll: SerialNumber definition
Cc: [e-mail], [e-mail]

Why the hell do we have object identifiers in RDNs, and not
numbers? 

> 
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}

It seems that the most simple solution is to add a new attribute
'the at-sign', or the stop sign. The attribute has no possible
values, its placement inside the RDN SEQUENCE indicates that everything
before defines the unique entity. 

At a first glance on might think to create an attribute that contains
some value (like serialnumber or unique id). but there is no need
to combine these different two functions, and it is even stupid,
because it might not even be necessary to have a Serialnumber. 

Of course the approach doesn't handle ALL posible theoretical cases
like multi-valued AVAs. And in some cases you need to reverse some
schema in order to have the right hierarchy. Who cares?

Peter Sylvester 


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27060 for <[e-mail]>; Wed, 23 Feb 2000 08:14:09 -0800 (PST)
Received: from mega (t1o69p83.telia.com [62.20.144.83]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA02273; Wed, 23 Feb 2000 17:21:10 +0100
Message-ID: <004d01bf7e21$6340e0c0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Plug'nPlay Certificates.  Was: SerialNumber definition
Date: Wed, 23 Feb 2000 17:13:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA27061

Stefan,
I keep my fingers crossed.

<snip>

>This is a predefined statement dedicated to include information that would
>clarify the actual content in the DN attributes.
>Lets say that we added another optional data element "dnIdentityMask" in the
>samanticsInformation:
>
>
>      SemanticsInformation ::= SEQUENCE {
>          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>          nameRegistrationAuthorities NameRegistrationAuthorities
>                                                          OPTIONAL
>          dnIdentityMask              DnIdentityMask   OPTIONAL}
>
>          DnIdentityMask ::= BIT STRING {
>               countryName             (0),
>               commonName              (1),
>               surname                 (2),
>               givenName               (3),
>               pseudonym               (4),
>               serialNumber            (5),
>               organizationName        (6),
>               organizationalUnitName  (7),
>               stateOrProvinceName     (8),
>               localityName            (9),
>               postalAddress          (10)}
>
>
>The defined meaning of dnIdentitymask would then be to specify the minimum
>set of attributes needed to obtain a unique identity of the subject, needed
>to identify the subject among all subjects handled by the CA.


Is not this not (in principle at least) exactly what Denis (and I in less formal way) suggested and 
was immediately rejected by others?

Well, if you REALLY plan to do changes what do you think of the Naming Domain addition I proposed
that should complement the package to allow what I would call Plug'nPlay Certificates?

What do you think of the impact of such a statement on cert comparisions? I (and Denis?)
think that existence such a statement should directly (or implicitly) indicate that you can do that.

I welcome such changes but I have almost lost faith in this process where "purity" (with respect
to X500) is given precedence over deployment and current practice.   I would though be very
worried to squeeze in all this in a week or so.  If you go ahead that will delay the process
another 4 weeks at least.  I have no problems whatsoever with that. 

BTW, why not reinstate dnqualifer although it is a little bit redundant as it is already in use?
In principle (sloppy, but this is where we are today) dnq should be used as name disambiguer and
serialnumber as some kind of more or less static indentity versus a naming domain.  Note: this is not
a high-priority issue but why "outlaw" something that has until very recently become suspect?  
I am now talking about son-of-RC2459 rather than just QC.

Anders




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26487 for <[e-mail]>; Wed, 23 Feb 2000 07:47:55 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA25604; Wed, 23 Feb 2000 16:52:02 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2000 16:51:50 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Andreas Berger <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andreas,

Thank you for attempting to provide some explanations.

> I will try to give some of the rationale behind the design of the German
> Signature Law as I understand it. You have to understand that the
> requirements were (and still are) not laid down in technical term and
> that - of course - there are different interpretations.
> 
> One basic design was the differentiation between the CA and the
> "information service". The CA issues the certificates and the
> information service - an entity that is a distinct organizational unit
> from the CA - revokes them. This can be interpreted as a technical
> realization of a division of duty which probably could have be solved
> with a requirement for the organizational procedures inside a CA.

Up here this is fine. There are two distinct entities, each one
using its own signing key, one for issuing certificates, and another
one for revoking certificates.

What is not said is whether a relying party will trust *directly*
only the CA key or both the CA key and the Revocation Authority key.
It has deep implications, in particular if the CA key is
compromised.

> Once such a division is made technically, it was extended to the idea
> that a certificate should only be valid once it is inserted in the
> information service database.

I do not understand. To be "valid" a certificate does not (even)
have to be published. It may be given back to the user who may
decide to send it to whatever entity he wishes.

> The law mentions the information service at one point:
> 
> Give that a CA ceases to operate, e.g. when being bankrupt or for what
> reason ever, the certificates are still valid (which is true, a
> revocation of the CA key is not necessary) iff the CA finds another
> trusted party that continues the operation of the information service
> and handles revocations. 

It only means that there must be "some way" to indicate which
Revocation Authority will continue to keep track of revocation
information for the already issued certificates from a given CA.
There is no need for a notion of insertion of certificates in a
public database.

> Accept that this is not a technical idea we
> had, it is an idea that the lawmakers had. But I do think that it has
> some truth in it.
> 
> Another point is that the compromise of a CA key may be a very seldom
> event but the potential cost, even with a desaster plan in place (anyone
> heard about one from any CA?) it may be desirable to have simple
> technical fallback position.

For that case, there exists simple fallback solutions that do not
require the use of an "information service database". The whole
Directory model from which X.509 certificates emerged is making the
assumption that there may be a Repository and, when that this
Repository exists, it is not trusted (this is why certificates are
signed by CAs).

> And a last remark to our OCSP extension: We extended basically the "not
> revoked" case to include extension. This should not disturb other
> systems that use the "not revoked" answer in the original CRL based way

The problem is more important than simply adding an additional
status.

Denis

> Andreas
> --
> Keine Zeit haben wir genug!


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25792 for <[e-mail]>; Wed, 23 Feb 2000 07:14:45 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA21048; Wed, 23 Feb 2000 16:19:00 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2000 16:18:48 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Straw Poll: SerialNumber definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Since the last call period is now open, let us attempt to
(hopefully) solve this issue within that period.

The solution to use the certPolicy OID proposed by Steve would not
work for an automated processing.
The solution proposed by Stefan would work, but I have something
simpler (but less flexible) that could possibly work.

Let is take a look at an old INFORMATIONAL RFC, i.e. RFC 1685
issused in August 1994. Its name is: Writing X.400 O/R Names.

Basically this document *recommends* a sequence for writing
distinguished names for human beings which is:

G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;

with:

    Given Name                             Given name        G
    Initial                                Initials          I
    Surname                                Surname           S
    Generation Qualifier                   Generation        Q
    Common Name                            Common Name       CN
    Organization                           Organization      O
    Organizational Unit 1                  Org.Unit.1        OU1
    Organizational Unit 2                  Org.Unit.2        OU2
    Organizational Unit 3                  Org.Unit.3        OU3
    Organizational Unit 4                  Org.Unit.4        OU4
    Private Management Domain Name         PRMD              P
    Administration Management Domain Name  ADMD              A
    Country                                Country           C

Suppose that now we introduce the new atribute called
UniqueIdentifier (UI), instead of SerialNumber which is a little bit
confusing.

The idea is that the *relative* placement of the UI in the DN chain
indicates to what it applies. In other words it serves like a
delimiter. Everything on the left of the delimiter has to be used to
make the name unique and permanent, for the given CA. If it comes
first, then it is self-sufficient by itself (e.g. it could be a
social security number or an employee number). In the following
example, it would only apply to G, I and S but not to O.

G=; I=; S=; UI= ; O=;

What do you think ?

Denis


> Guys,
> 
> I may have a nice solution to this debate.
> 
> May I first draw your attention once again to the fact that the solution in
> the qcStatement extension almost have what you ask for in the first place.
> 
> What we have is a predefined statement in QC 03 saying:
> 
>    3.2.5.1 Predefined Statements
> 
>    This profile includes one predefined object identifier (id-qcs-
>    pkixQCSyntax-v1), identifying conformance with syntax and semantics
>    defined in this profile. This Qualified Certificate profile is
>    referred to as version 1.
> 
>       qcStatement-1 QC-STATEMENT ::= { SemanticsInformation IDENTIFIED
>           BY id-qcs-pkixQCSyntax-v1 }
>       --  This statement identifies conformance with syntax and
>       --  semantics defined in this Qualified Certificate profile
>       --  (Version 1). The SemanticsInformation may optionally contain
>       --  additional semantics information as specified.
> 
>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL }
>           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
>            WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
> 
>       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
>           GeneralName
> 
> This is a predefined statement dedicated to include information that would
> clarify the actual content in the DN attributes.
> Lets say that we added another optional data element "dnIdentityMask" in the
> samanticsInformation:
> 
>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           dnIdentityMask              DnIdentityMask   OPTIONAL}
> 
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}
> 
> The defined meaning of dnIdentitymask would then be to specify the minimum
> set of attributes needed to obtain a unique identity of the subject, needed
> to identify the subject among all subjects handled by the CA.
> 
> The good side of this solution is that it can be used without any need to
> define a new OID, since the attribute semantics OID is optional.
> 
> This solution could in a nice way satisfy all needs raised in the discussion
> without breaking any current practice or stretch any intended definitions or
> structures.
> 
> I guess that this could be considered as a minor adjustments to be included
> without requiring a new last call period.
> 
> Thoughts, comments?
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Anders Rundgren [mailto:[e-mail]]
> > Sent: Wednesday, February 23, 2000 10:00 AM
> > To: Denis Pinkas; Stephen Kent
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Straw Poll: SerialNumber definition
> >
> >
> > Steve,
> >
> > <snip>
> > >I'm opposed to adding a notion of selective marking of RDNs to
> > >indicate which ones, in concert, really qualify as a DN, remembering
> > >the definition of a DN.  This was the subject of a private message
> > >exchange between Anders and me last week, so I'm happy to share my
> > >thoughts on this topic.
> > >
> > >The notion underlying this proposal seems to be that DNs are
> > >convenient ways to express human readable names, but that in using
> > >them we should abandon all notions of the DIT context from
> > which they
> > >emanated.
> >
> > Not abandon, a DN would still be a DN.  Heritage is of less interest.
> > The solution is a technical way to solve something that is
> > already performed using
> > "local knowledge and manual settings" by a lot of current RP software.
> >
> > > A purer way to address this need would be to define a new
> > >name type under general names (we have a couple of options for this
> > >in GNs), but this would not be backward compatible with
> > existing apps
> > >that already have some ability to parse DNs, but not all forms of
> > >GNs, much less a new form.
> >
> > As compatibility with existing SW is crucial, some purity
> > will have to be sacrificed.
> > For radical changes like GNs it may be better to look on
> > XML-certs but that is another story.
> >
> > <snip>
> >
> > >I think a better approach to the base problem that motivated this
> > >debate is to use an extension that claims to be a unique ID for the
> > >subject, relative to the Issuer.  But, we already have such a value,
> > >in the form of the SubjectUniqueID, if we really want this feature!
> >
> > As Denis nicely points out, the suggested solution allows
> > arbitrary uses
> > of DN attributes including various combinations with serialNumber and
> > lets say organizationUnit.   But for the RP it looks like a
> > singular solution
> > as it just requires a call to the (anticipated) API function
> > "getQCUnmistakableIdenitity()"
> > to get the optional subset of of DN that holds the
> > unmistakable identity.
> > That is what I call GENERIC SOLUTION and is what standards need.
> >
> > SubjectUniqueID is a SPECIAL CASE of no general interest.
> >
> > <snip>
> >
> > >certs contain subject DNs that differ in other attributes?  Well,
> > >since all the other proposals for selective RDN use require some
> > >means of signalling RP software, why not use a cert policy
> > OID?  It's
> > >just as valid a means of signalling this non-standard
> > interpretation,
> > >for the set of RP software that will need to make use of this fact.
> >
> > Unfortunately NON-STANDARD policy OIDs create much more problems than
> > they solve.  I have already elaborated on that in this list.
> >
> > What is missing from the current suggestion is a Naming
> > Domain definition.
> > I can just find two variants: Either the naming domain is
> > marked as internal/CA
> > and does not have to be known outside, or the CA issues
> > certificates to
> > an external naming domain like "registered Citizen of XYZ".
> > The latter should
> > require an officially registered value of some kind to be
> > interoperable among
> > competing CAs,
> >
> > Conclusion: the maintenance and setup of QC RP SW  can be
> > really greatly simplified!
> >
> > OK, it does not solve the actual meaning of OU, CN, and SN
> > etc. but somewhere you
> > have to stop!
> >
> > Anders
> >
> > PS Steve, do you prefer that a solution according to my and
> > Denis lines are
> > taken to PKI-FORUM rather than developed here?  I don't care where as
> > long as it gets done.  DS
> >
> >


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25333 for <[e-mail]>; Wed, 23 Feb 2000 06:57:29 -0800 (PST)
Received: from darmstadt.gmd.de (aberger@pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA27829; Wed, 23 Feb 2000 15:59:54 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2000 15:59:54 +0100
From: Andreas Berger <[e-mail]>
Organization: GMD SIT.SICA Darmstadt
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Simon Tardell <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I will try to give some of the rationale behind the design of the German
Signature Law as I understand it. You have to understand that the
requirements were (and still are) not laid down in technical term and
that - of course - there are different interpretations.

One basic design was the differentiation between the CA and the
"information service". The CA issues the certificates and the
information service - an entity that is a distinct organizational unit
from the CA - revokes them. This can be interpreted as a technical
realization of a division of duty which probably could have be solved
with a requirement for the organizational procedures inside a CA.

Once such a division is made technically, it was extended to the idea
that a certificate should only be valid once it is inserted in the
information service database.

The law mentions the information service at one point:

Give that a CA ceases to operate, e.g. when being bankrupt or for what
reason ever, the certificates are still valid (which is true, a
revocation of the CA key is not necessary) iff the CA finds another
trusted party that continues the operation of the information service
and handles revocations. Accept that this is not a technical idea we
had, it is an idea that the lawmakers had. But I do think that it has
some truth in it.

Another point is that the compromise of a CA key may be a very seldom
event but the potential cost, even with a desaster plan in place (anyone
heard about one from any CA?) it may be desirable to have simple
technical fallback position.

And a last remark to our OCSP extension: We extended basically the "not
revoked" case to include extension. This should not disturb other
systems that use the "not revoked" answer in the original CRL based way

Andreas
-- 
Keine Zeit haben wir genug!


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24216 for <[e-mail]>; Wed, 23 Feb 2000 05:34:22 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id FAA15790; Wed, 23 Feb 2000 05:33:40 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 22 Feb 2000 22:36:58 -0500
To: "william bamberg" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Diffie-Hellman DomainParameters question
Cc: <[e-mail]>
In-Reply-To: <025401bf7d4f$6186b610$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Will:

Two reasons, one political and one technical.

1.  This structure is aligned with the ANSI X9.42 standard.  The banking 
community and the Internet community will be using the same structure.

2.  The value of q is needed to avoid some small subgroup attacks.  See 
draft-ietf-smime-small-subgroup-03.txt.

Russ



At 04:10 PM 02/22/2000 +0000, william bamberg wrote:
>RFC 2459, and the new draft, both specify the DomainParameters to be
>included along with a D-H public key value with the following syntax:
>
>         DomainParameters ::= SEQUENCE {
>               p       INTEGER, -- odd prime, p=jq +1
>               g       INTEGER, -- generator, g
>               q       INTEGER, -- factor of p-1
>               j       INTEGER OPTIONAL, -- subgroup factor
>               validationParms  ValidationParms OPTIONAL }
>
>I'm not a crypto expert, but I understand that the q value is not actually
>essential for doing Diffie-Hellman, and most D-H certificates that I've come
>across seem to omit it. Could anyone explain to me why it's not optional in
>the spec?
>
>Thanks very much
>
>Will
>
>



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22767 for <[e-mail]>; Wed, 23 Feb 2000 03:24:50 -0800 (PST)
Received: from Santesson (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA18070; Wed, 23 Feb 2000 12:28:44 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 13:28:51 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <[e-mail]>

Guys,

I may have a nice solution to this debate.

May I first draw your attention once again to the fact that the solution in
the qcStatement extension almost have what you ask for in the first place.

What we have is a predefined statement in QC 03 saying:

   3.2.5.1 Predefined Statements

   This profile includes one predefined object identifier (id-qcs-
   pkixQCSyntax-v1), identifying conformance with syntax and semantics
   defined in this profile. This Qualified Certificate profile is
   referred to as version 1.

      qcStatement-1 QC-STATEMENT ::= { SemanticsInformation IDENTIFIED
          BY id-qcs-pkixQCSyntax-v1 }
      --  This statement identifies conformance with syntax and
      --  semantics defined in this Qualified Certificate profile
      --  (Version 1). The SemanticsInformation may optionally contain
      --  additional semantics information as specified.

      SemanticsInformation ::= SEQUENCE {
          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
          nameRegistrationAuthorities NameRegistrationAuthorities
                                                          OPTIONAL }
          (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
           WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})

      NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
          GeneralName


This is a predefined statement dedicated to include information that would
clarify the actual content in the DN attributes.
Lets say that we added another optional data element "dnIdentityMask" in the
samanticsInformation:


      SemanticsInformation ::= SEQUENCE {
          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
          nameRegistrationAuthorities NameRegistrationAuthorities
                                                          OPTIONAL
          dnIdentityMask              DnIdentityMask   OPTIONAL}

          DnIdentityMask ::= BIT STRING {
               countryName             (0),
               commonName              (1),
               surname                 (2),
               givenName               (3),
               pseudonym               (4),
               serialNumber            (5),
               organizationName        (6),
               organizationalUnitName  (7),
               stateOrProvinceName     (8),
               localityName            (9),
               postalAddress          (10)}


The defined meaning of dnIdentitymask would then be to specify the minimum
set of attributes needed to obtain a unique identity of the subject, needed
to identify the subject among all subjects handled by the CA.

The good side of this solution is that it can be used without any need to
define a new OID, since the attribute semantics OID is optional.

This solution could in a nice way satisfy all needs raised in the discussion
without breaking any current practice or stretch any intended definitions or
structures.

I guess that this could be considered as a minor adjustments to be included
without requiring a new last call period.


Thoughts, comments?


/Stefan




> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Wednesday, February 23, 2000 10:00 AM
> To: Denis Pinkas; Stephen Kent
> Cc: [e-mail]; [e-mail]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
> Steve,
>
> <snip>
> >I'm opposed to adding a notion of selective marking of RDNs to
> >indicate which ones, in concert, really qualify as a DN, remembering
> >the definition of a DN.  This was the subject of a private message
> >exchange between Anders and me last week, so I'm happy to share my
> >thoughts on this topic.
> >
> >The notion underlying this proposal seems to be that DNs are
> >convenient ways to express human readable names, but that in using
> >them we should abandon all notions of the DIT context from
> which they
> >emanated.
>
> Not abandon, a DN would still be a DN.  Heritage is of less interest.
> The solution is a technical way to solve something that is
> already performed using
> "local knowledge and manual settings" by a lot of current RP software.
>
> > A purer way to address this need would be to define a new
> >name type under general names (we have a couple of options for this
> >in GNs), but this would not be backward compatible with
> existing apps
> >that already have some ability to parse DNs, but not all forms of
> >GNs, much less a new form.
>
> As compatibility with existing SW is crucial, some purity
> will have to be sacrificed.
> For radical changes like GNs it may be better to look on
> XML-certs but that is another story.
>
> <snip>
>
> >I think a better approach to the base problem that motivated this
> >debate is to use an extension that claims to be a unique ID for the
> >subject, relative to the Issuer.  But, we already have such a value,
> >in the form of the SubjectUniqueID, if we really want this feature!
>
> As Denis nicely points out, the suggested solution allows
> arbitrary uses
> of DN attributes including various combinations with serialNumber and
> lets say organizationUnit.   But for the RP it looks like a
> singular solution
> as it just requires a call to the (anticipated) API function
> "getQCUnmistakableIdenitity()"
> to get the optional subset of of DN that holds the
> unmistakable identity.
> That is what I call GENERIC SOLUTION and is what standards need.
>
> SubjectUniqueID is a SPECIAL CASE of no general interest.
>
> <snip>
>
> >certs contain subject DNs that differ in other attributes?  Well,
> >since all the other proposals for selective RDN use require some
> >means of signalling RP software, why not use a cert policy
> OID?  It's
> >just as valid a means of signalling this non-standard
> interpretation,
> >for the set of RP software that will need to make use of this fact.
>
> Unfortunately NON-STANDARD policy OIDs create much more problems than
> they solve.  I have already elaborated on that in this list.
>
> What is missing from the current suggestion is a Naming
> Domain definition.
> I can just find two variants: Either the naming domain is
> marked as internal/CA
> and does not have to be known outside, or the CA issues
> certificates to
> an external naming domain like "registered Citizen of XYZ".
> The latter should
> require an officially registered value of some kind to be
> interoperable among
> competing CAs,
>
> Conclusion: the maintenance and setup of QC RP SW  can be
> really greatly simplified!
>
> OK, it does not solve the actual meaning of OU, CN, and SN
> etc. but somewhere you
> have to stop!
>
> Anders
>
> PS Steve, do you prefer that a solution according to my and
> Denis lines are
> taken to PKI-FORUM rather than developed here?  I don't care where as
> long as it gets done.  DS
>
>



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13833 for <[e-mail]>; Tue, 22 Feb 2000 23:59:54 -0800 (PST)
Received: from mega (t2o69p45.telia.com [62.20.144.165]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA24794; Wed, 23 Feb 2000 09:07:08 +0100
Message-ID: <001801bf7ddc$5f3e0380$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 08:59:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA13834

Steve,

<snip>
>I'm opposed to adding a notion of selective marking of RDNs to 
>indicate which ones, in concert, really qualify as a DN, remembering 
>the definition of a DN.  This was the subject of a private message 
>exchange between Anders and me last week, so I'm happy to share my 
>thoughts on this topic.
>
>The notion underlying this proposal seems to be that DNs are 
>convenient ways to express human readable names, but that in using 
>them we should abandon all notions of the DIT context from which they 
>emanated.

Not abandon, a DN would still be a DN.  Heritage is of less interest.
The solution is a technical way to solve something that is already performed using
"local knowledge and manual settings" by a lot of current RP software.

> A purer way to address this need would be to define a new 
>name type under general names (we have a couple of options for this 
>in GNs), but this would not be backward compatible with existing apps 
>that already have some ability to parse DNs, but not all forms of 
>GNs, much less a new form.

As compatibility with existing SW is crucial, some purity will have to be sacrificed.
For radical changes like GNs it may be better to look on XML-certs but that is another story.

<snip>  

>I think a better approach to the base problem that motivated this 
>debate is to use an extension that claims to be a unique ID for the 
>subject, relative to the Issuer.  But, we already have such a value, 
>in the form of the SubjectUniqueID, if we really want this feature!

As Denis nicely points out, the suggested solution allows arbitrary uses
of DN attributes including various combinations with serialNumber and
lets say organizationUnit.   But for the RP it looks like a singular solution
as it just requires a call to the (anticipated) API function "getQCUnmistakableIdenitity()"
to get the optional subset of of DN that holds the unmistakable identity.
That is what I call GENERIC SOLUTION and is what standards need.

SubjectUniqueID is a SPECIAL CASE of no general interest.

<snip>

>certs contain subject DNs that differ in other attributes?  Well, 
>since all the other proposals for selective RDN use require some 
>means of signalling RP software, why not use a cert policy OID?  It's 
>just as valid a means of signalling this non-standard interpretation, 
>for the set of RP software that will need to make use of this fact.

Unfortunately NON-STANDARD policy OIDs create much more problems than
they solve.  I have already elaborated on that in this list.

What is missing from the current suggestion is a Naming Domain definition.
I can just find two variants: Either the naming domain is marked as internal/CA
and does not have to be known outside, or the CA issues certificates to
an external naming domain like "registered Citizen of XYZ".   The latter should
require an officially registered value of some kind to be interoperable among
competing CAs,

Conclusion: the maintenance and setup of QC RP SW  can be really greatly simplified!

OK, it does not solve the actual meaning of OU, CN, and SN etc. but somewhere you
have to stop!

Anders

PS Steve, do you prefer that a solution according to my and Denis lines are
taken to PKI-FORUM rather than developed here?  I don't care where as
long as it gets done.  DS





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26658 for <[e-mail]>; Tue, 22 Feb 2000 16:52:48 -0800 (PST)
Received: from [128.33.238.49] (TC013.BBN.COM [128.33.238.13]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA13970; Tue, 22 Feb 2000 19:56:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080fb4d8daaa49cc@[128.33.238.49]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 22 Feb 2000 19:56:52 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: [e-mail], "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Denis,

>...
>
>In addition to these two extremes (all versus none), there is a
>number of variations where the dnq (DN Qualifier) does not apply to
>all or none, but to *some* of the components of the DN. This would
>solve other concerns raised on that thread.
>
>All concepts could nicely co-exist if we could find a way to say on
>*which* components of the DN the dnq (DN Qualifier) would apply.
>Rather than leaving the interpretation to an (unprocessable)
>Certificate Policy OID, we should define a way to express which
>components of the RDN should be associated with the dnq to make the
>name unmistakable and *permanently* unique.

I'm opposed to adding a notion of selective marking of RDNs to 
indicate which ones, in concert, really qualify as a DN, remembering 
the definition of a DN.  This was the subject of a private message 
exchange between Anders and me last week, so I'm happy to share my 
thoughts on this topic.

The notion underlying this proposal seems to be that DNs are 
convenient ways to express human readable names, but that in using 
them we should abandon all notions of the DIT context from which they 
emanated.  A purer way to address this need would be to define a new 
name type under general names (we have a couple of options for this 
in GNs), but this would not be backward compatible with existing apps 
that already have some ability to parse DNs, but not all forms of 
GNs, much less a new form.  But RFC 2459 already rejects the notion 
of misusing DNs to express other name forms, despite historical 
precedents, e.g., we disparage sticking RCC 822 names or IP addresses 
in DNs (typically in the guise of the common name attribute).  So, if 
we have insisted on using appropriate name forms for these other name 
types, despite possible backward compatibility problems, why should 
we backtrack when it comes to the notion of creating a new form of 
name, i.e., a DN in which only some RDNS are meaningful?

I think a better approach to the base problem that motivated this 
debate is to use an extension that claims to be a unique ID for the 
subject, relative to the Issuer.  But, we already have such a value, 
in the form of the SubjectUniqueID, if we really want this feature!

Finally, I question the assertion that there is a problem to be fixed 
here, at least in the base spec (2459).   With the current plans to 
use serialNumber as a disambiguator everyone agrees that we have 
addressed the first of the two possible uses.  However, if one wants 
to have this value be unique, relative to the Issuer, that seems 
consistent with the definition now proposed, even though it is 
overkill, i.e., it is still a disambiguator.  How should a CA express 
the notion that this RDN uniquely identifies the subject, even if two 
certs contain subject DNs that differ in other attributes?  Well, 
since all the other proposals for selective RDN use require some 
means of signalling RP software, why not use a cert policy OID?  It's 
just as valid a means of signalling this non-standard interpretation, 
for the set of RP software that will need to make use of this fact.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25528 for <[e-mail]>; Tue, 22 Feb 2000 15:53:45 -0800 (PST)
Received: from [128.33.238.49] (TC049.BBN.COM [128.33.238.49]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA10146; Tue, 22 Feb 2000 18:57:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b4d8cf75a615@[128.33.238.14]>
In-Reply-To: <01BF7D59.061F9E40@HYDRA>
References: <01BF7D59.061F9E40@HYDRA>
Date: Tue, 22 Feb 2000 18:43:42 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SEIS:  RE: WG last call for draft-ietf-pkix-qc-o3.txt
Cc: "'[e-mail]'" 	 <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" 	 <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>--- Message on the SEIS mailing list ([e-mail])
>
>Interesting timing of a last call :-)
>

Stefan asked me to initiate the last call 2 weeks ago, but travel and 
forgetfulness on my part delayed the message.

Steve



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22458 for <[e-mail]>; Tue, 22 Feb 2000 11:44:38 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA27051; Tue, 22 Feb 2000 11:48:26 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 22 Feb 2000 11:49:03 -0800
To: Paul Koning <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:43 AM 02/21/2000 -0500, Paul Koning wrote:
> >>>>> "Denis" == Denis Pinkas <[e-mail]> writes:
>
>  Denis> As David Kemp noticed it there are two ways to use additional
>  Denis> RDN attributes:
>
>  Denis> 1) as a disambiguator,
>
>  Denis> Originally the idea was to add a disambiguator only in the
>  Denis> case where two certificates, without the disambiguator, would
>  Denis> contain identical DNs.
>
>  Denis> 2) as a static identifier.
>
>  Denis> Originally the idea was to use the static identifier without
>  Denis> using the other DN components, which meant that the static
>  Denis> identifier was sufficient to identify an individual.
>
>  Denis> The first case means that *all* the components of the DN are
>  Denis> used in conjunction with the dnq (DN Qualifier), while the
>  Denis> second means that *none* of the components of the DN are used
>  Denis> in conjunction with the dnq (DN Qualifier).
>
>  Denis> In addition to these two extremes (all versus none), there is
>  Denis> a number of variations where the dnq (DN Qualifier) does not
>  Denis> apply to all or none, but to *some* of the components of the
>  Denis> DN. This would solve other concerns raised on that thread.
>
>Ouch.
>
>The situation we started from is that there were two ways of
>interpreting a particular attribute.  The new situation you're
>pointing to is to increase that number from 2 to N.  I think that's a
>large step in the wrong direction.
>
>The problem with many standards is that they have too many options,
>not too few.  Adding more stuff for the purpose of adding N-2 new
>options is not a good thing at all, in my view.
>
>         paul

In retrospect, had a value been built-in to the spec, indicating
which subset of DN/RDN attributes constitute "unique-id" from an
issuing CAs perspective, it could be seen as reducing 2 ways to 1.
I.E., ALWAYS rely on the given subset specification.  While this
would make processing mechanical, it would not help in promoting
a "common uniqueness profile" if that is the real concern.

___tony___


___tony___
Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21627 for <[e-mail]>; Tue, 22 Feb 2000 10:55:26 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA21226 for <[e-mail]>; Wed, 23 Feb 2000 07:59:23 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <95124596321623>; Wed, 23 Feb 2000 07:59:23 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Diffie-Hellman DomainParameters question
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 23 Feb 2000 07:59:23 (NZDT)
Message-ID: <[e-mail]>

"william bamberg" <[e-mail]> writes:

>I'm not a crypto expert, but I understand that the q value is not actually
>essential for doing Diffie-Hellman, and most D-H certificates that I've come
>across seem to omit it. Could anyone explain to me why it's not optional in
>the spec?

This is required by the particular version of X9.42 which was current when the
RFC 2459 draft was written, <grumble>ignoring the fact that pretty much the 
only thing which uses DH and DH certs is SSL/Skip/etc, which use PKCS #3 
DH</grumble>.

(I was very restrained there, I didn't post the 3-page rant which any mention
 of X9.42 usually triggers :-).

Peter.



Received: from gatekeeper2.novartis.com (gatekeeper2.novartis.com [194.191.169.74]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15819 for <[e-mail]>; Tue, 22 Feb 2000 08:54:18 -0800 (PST)
From: [e-mail]
Received: from mta3.is.chbs (mta3.novartis.com [192.37.10.59]) by gatekeeper2.novartis.com (8.9.3/8.9.3) with ESMTP id RAA31759 for <[e-mail]>; Tue, 22 Feb 2000 17:57:41 +0100 (MET)
Received: from nts1.novartis.com (n1chbs-s0109.is.chbs [192.168.50.131]) by mta3.is.chbs (8.9.3/8.9.3) with SMTP id RAA06911 for <[e-mail]>; Tue, 22 Feb 2000 17:56:41 +0100 (MET)
Received: by nts1.novartis.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 4125688D.005D2AC1 ; Tue, 22 Feb 2000 17:57:37 +0100
X-Lotus-FromDomain: PH@N1
To: "'[e-mail]'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 22 Feb 2000 11:54:02 -0500
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from np-mailhub.dlj.com (smtp3.dlj.com [199.105.64.197]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14621 for <[e-mail]>; Tue, 22 Feb 2000 08:32:38 -0800 (PST)
Received: from dljmail04.ct.dlj.com ([170.61.50.203]) by np-mailhub.dlj.com (8.9.1/8.9.1) with ESMTP id LAA06725 for <[e-mail]>; Tue, 22 Feb 2000 11:28:55 -0500 (EST)
Received: by DLJMAIL04 with Internet Mail Service (5.5.2448.0) id <1K2BA2VT>; Tue, 22 Feb 2000 11:35:08 -0500
Message-ID: <722BF44E3961D311B50A00204804FE38B6EC76@DLJMAIL27>
From: "Mahmood, Mohsin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Tue, 22 Feb 2000 11:33:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe

-----Original Message-----
From: Meggison, Tim [mailto:[e-mail]]
Sent: Tuesday, February 22, 2000 11:06 AM
To: 'Russ Housley'
Cc: '[e-mail]'
Subject: RE: Cert chain validation


If the policy extensions in all the certs are marked non-critical, is it
valid for a Relying Party to ignore the policy extensions during path
validation, but still display any associated User Notices?

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, February 22, 2000 10:19 AM
To: Meggison, Tim
Cc: '[e-mail]'
Subject: Re: Cert chain validation


Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying
Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued
with
>a policy oid of 1.2.4.1?


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14133 for <[e-mail]>; Tue, 22 Feb 2000 08:24:25 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA02664; Tue, 22 Feb 2000 17:31:43 +0100
Received: by HYDRA with Microsoft Mail id <01BF7D59.061F9E40@HYDRA>; Tue, 22 Feb 2000 17:19:49 +0100
Message-ID: <01BF7D59.061F9E40@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: WG last call for draft-ietf-pkix-qc-o3.txt
Date: Tue, 22 Feb 2000 17:19:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Interesting timing of a last call :-)

I agree that the things that have been discussed recently are too late to add
without really screwing up the whole project.

I though really lack some rules for a QUALIFIED CA like

DN interpretation/unmistakable identity that should be DECLARED
Naming domain that should be DECLARED
The possibility to compare certs from a certain CA that should be DECLARED

Note: This would not break anything, just improve security, usability and interoperability.

Anders

----------
From:  Stephen Kent [SMTP:[e-mail]]
Sent:  Tuesday, February 22, 2000 04:00
To:  [e-mail]
Subject:  WG last call for draft-ietf-pkix-qc-o3.txt

I am initiating a 2 week last call on the Internet Draft on Qualified 
Certificates, as indicated in the subject line of this message.

I realize that there is some continuing debate on issues of what 
parts of a DN should be considered essential for uniquely identifying 
the Subject of a certificate. However, this is a broader issue, not 
restricted to QCs, and I expect that it will not be resolved quickly. 
Since the QC document have evolved through a series of drafts and the 
editor has made appropriate changes reflecting WG consensus at each 
stage, it is appropriate to initiate last call at this time.

Steve Kent
PKIX WG Co-chair



Received: from symbianuk05.symbian.com ([194.200.144.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13135 for <[e-mail]>; Tue, 22 Feb 2000 08:04:53 -0800 (PST)
Received: from lon-williamb ([10.151.15.235]) by symbianuk05.symbian.com (Lotus Domino Release 5.0.1b (Intl)) with SMTP id 2000022216094226:38901 ; Tue, 22 Feb 2000 16:09:42 +0000 
Message-ID: <025401bf7d4f$6186b610$[e-mail]>
From: "william bamberg" <[e-mail]>
To: <[e-mail]>
Subject: Diffie-Hellman DomainParameters question
Date: Tue, 22 Feb 2000 16:10:44 -0000
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-MIMETrack: Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 22/02/2000 16:09:42, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 22/02/2000 16:10:13, Serialize complete at 22/02/2000 16:10:13
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"

RFC 2459, and the new draft, both specify the DomainParameters to be
included along with a D-H public key value with the following syntax:

        DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

I'm not a crypto expert, but I understand that the q value is not actually
essential for doing Diffie-Hellman, and most D-H certificates that I've come
across seem to omit it. Could anyone explain to me why it's not optional in
the spec?

Thanks very much

Will






Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12876 for <[e-mail]>; Tue, 22 Feb 2000 08:02:07 -0800 (PST)
Received: from ctex01.us.cybertrust.com (ctex01.us.cybertrust.com [192.233.30.4]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA12288; Tue, 22 Feb 2000 11:05:43 -0500 (EST)
Received: by ctex01.us.cybertrust.com with Internet Mail Service (5.5.2650.21) id <DF6Z028T>; Tue, 22 Feb 2000 11:06:15 -0500
Message-ID: <[e-mail]>
From: "Meggison, Tim" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Cert chain validation
Date: Tue, 22 Feb 2000 11:06:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

If the policy extensions in all the certs are marked non-critical, is it
valid for a Relying Party to ignore the policy extensions during path
validation, but still display any associated User Notices?

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, February 22, 2000 10:19 AM
To: Meggison, Tim
Cc: '[e-mail]'
Subject: Re: Cert chain validation


Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying
Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued
with
>a policy oid of 1.2.4.1?


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11594 for <[e-mail]>; Tue, 22 Feb 2000 07:32:49 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA05059; Tue, 22 Feb 2000 07:31:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 22 Feb 2000 10:19:25 -0500
To: "Meggison, Tim" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Cert chain validation
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] t.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued with
>a policy oid of 1.2.4.1?



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03178 for <[e-mail]>; Tue, 22 Feb 2000 02:23:07 -0800 (PST)
Received: from npwork2 (e1h2p26.scotland.net [148.176.234.27]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id KAA23531; Tue, 22 Feb 2000 10:27:04 GMT
From: "Nick Pope" <[e-mail]>
To: "Schwarz, Bernhard" <[e-mail]>, <[e-mail]>
Subject: RE: using more than one public key
Date: Tue, 22 Feb 2000 10:35:03 -0000
Message-ID: <002001bf7d20$7a84eb20$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <C7F148D48CBAD211B3DA00A0C9F00FE7A1298E@U8N32>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

his was a basic issue which was considered when deveoping the X.509
extensions and the decision was to keep to the rule that one X.509
certificate should have one AND ONLY ONE key.

Nick Pope

> -----Original Message-----
> From: Schwarz, Bernhard [mailto:[e-mail]]
> Sent: 22 February 2000 09:30
> To: [e-mail]
> Subject: using more than one public key
>
>
> Trying to understand draft-ietf-pkix-qc-03.txt, Chapter 4,
> the following question appeared:
> If we have a Qualified Certificate containing more than one
> public key (different key pairs used for different purposes),
> is the strictly pointed out declaration
>    "... The associated private keys must be unique for the
>    subject, and must be maintained under the subject's sole
>    control. ..."
> to be used for each private key, the public key of which is
> provided in this certificate or only for the key(s) especially
> provided for non-repudiation use?
> Can somebody make that clear?
>
> Thank You
> Bernhard Schwarz
>



Received: from fw1a.telekom.de (gw1.telekom.de [194.25.15.11]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29657 for <[e-mail]>; Tue, 22 Feb 2000 01:26:44 -0800 (PST)
Received: by fw1a.telekom.de; (5.65v4.0/1.3/10May95) id AA28051; Tue, 22 Feb 2000 10:30:42 +0100
Received: from Q8N09.bmbg01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for [e-mail]; Tue, 22 Feb 2000 10:30:30 +0100
Received: from u8n10.bmbg01.telekom.de by q8n09.bmbg01.telekom.de with ESMTP for [e-mail]; Tue, 22 Feb 2000 10:30:17 +0100
Received: by U8N10.bmbg01.telekom.de with Internet Mail Service (5.5.2650.21) id <1PJ368M3>; Tue, 22 Feb 2000 10:30:17 +0100
Message-Id: <C7F148D48CBAD211B3DA00A0C9F00FE7A1298E@U8N32>
From: "Schwarz, Bernhard" <[e-mail]>
To: [e-mail]
Subject: using more than one public key
Date: Tue, 22 Feb 2000 10:30:08 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Trying to understand draft-ietf-pkix-qc-03.txt, Chapter 4,
the following question appeared:
If we have a Qualified Certificate containing more than one
public key (different key pairs used for different purposes),
is the strictly pointed out declaration
   "... The associated private keys must be unique for the
   subject, and must be maintained under the subject's sole
   control. ..."
to be used for each private key, the public key of which is
provided in this certificate or only for the key(s) especially
provided for non-repudiation use?
Can somebody make that clear?

Thank You
Bernhard Schwarz


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08687 for <[e-mail]>; Mon, 21 Feb 2000 18:54:34 -0800 (PST)
Received: from [128.33.238.14] (TC014.BBN.COM [128.33.238.14]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA29219 for <[e-mail]>; Mon, 21 Feb 2000 21:58:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b4d7ab1ef26e@[128.33.238.14]>
Date: Mon, 21 Feb 2000 21:59:45 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call for draft-ietf-pkix-qc-o3.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I am initiating a 2 week last call on the Internet Draft on Qualified 
Certificates, as indicated in the subject line of this message.

I realize that there is some continuing debate on issues of what 
parts of a DN should be considered essential for uniquely identifying 
the Subject of a certificate. However, this is a broader issue, not 
restricted to QCs, and I expect that it will not be resolved quickly. 
Since the QC document have evolved through a series of drafts and the 
editor has made appropriate changes reflecting WG consensus at each 
stage, it is appropriate to initiate last call at this time.

Steve Kent
PKIX WG Co-chair


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01530 for <[e-mail]>; Mon, 21 Feb 2000 16:15:00 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA26010 for <[e-mail]>; Tue, 22 Feb 2000 11:18:21 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdSBbVA_; Tue Feb 22 11:17:58 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA08002 for <[e-mail]>; Tue, 22 Feb 2000 11:17:58 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd00_73H; Tue Feb 22 11:17:09 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA01603 for <[e-mail]>; Tue, 22 Feb 2000 11:17:09 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <FDLGBRVB>; Tue, 22 Feb 2000 11:16:49 +1100
Message-ID: <73388857A695D31197EF00508B08F2988A3AF2@NTMSG0131>
From: "Manger, James H" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Timestamp: 05: LAST CALL - editorial corrections
Date: Tue, 22 Feb 2000 11:16:46 +1100
X-MS-TNEF-Correlator: <73388857A695D31197EF00508B08F2988A3AF2@NTMSG0131>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF7CCA.1B1C0F48"

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

------_=_NextPart_000_01BF7CCA.1B1C0F48
Content-Type: text/plain;
	charset="iso-8859-1"

The TimeStampToken is never defined in ASN.1, not even in the ASN.1 module.
Add to 2.4.2 Response Format, above SignedData definition:
	TimeStampToken ::= ContentInfo -- content type is signedData --
Also add this to Appendix D: ASN.1 module, and include ContentInfo in the
IMPORTS section.
I would also rephrase the text description of TimeStampToken.  It
encapsulates a SignedData value, not the other way around.
Replace the paragraph "A TimeStampToken is as follows .. type SignedData" in
2.4.2 with:
	A TimeStampToken value encapsulates a SignedData value [CMS] that
encapsulates a TSTInfo value.

Appendix D: ASN.1 module lists SignedData and ESSCertID in the IMPORTS
section.  Neither of these are used in the ASN.1 module so delete them from
the IMPORTS section.


------_=_NextPart_000_01BF7CCA.1B1C0F48
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjIAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0AcCABYACwAQAC4AAgA6AQEggAMADgAAANAHAgAW
AAsAEAAuAAIAOgEBCYABACEAAABFMEI4MUVFN0EyRThEMzExOTdGOTAwNTA4QjA4RjI5OAApBwEE
gAEANQAAAFJFOiBUaW1lc3RhbXA6IDA1OiBMQVNUIENBTEwgLSBlZGl0b3JpYWwgY29ycmVjdGlv
bnMAIxEBDYAEAAIAAAACAAIAAQOQBgBwCAAANQAAAAMA3j+vbwAAAwAAgAggBgAAAAAAwAAAAAAA
AEYAAAAAUoUAAPATAAAeAAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUACwAN
gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAABhQAA
AAAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYA
AAAADoUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABoAIIAYAAAAAAMAA
AAAAAABGAAAAABGFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAiACCAG
AAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAA
N4UAAAEAAAABAAAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAL
AA6ACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsAD4ALIAYAAAAAAMAAAAAAAABGAAAAAAWI
AAAAAAAAAgEJEAEAAABwAgAAbAIAAOYDAABMWkZ1qogR6wMACgByY3BnMTI1BjIA+AtgbmczMDg6
MQH3IAKkA+MCAGNowQrAc2V0MCAHEwKAZn0KgAjIIDsJbw4wNbMCgAqBdWMAUAsDYwBBIQ8CMTAz
MwxgbG6FAiBlC6YgVGhlFrAFB3FTAZBtcFRva1UJ8CAEACAWEHYEkCAfAQELgAmAF+ADoEFTTugu
MSwYEG8FQBgxF9FtA6B0FtEZMyAEYRXQZSYuCqIKgEFkGOB0b8AgMi40LjIH8AeQZnACIBEwIEYF
sADAdJsZgAGgbxhABgBpZxjBikQdcGEYdGl0aQIgDjobdAyCFv46Oj0gRwhQAjAJ8HRJbgIQIOQt
LQMwaSAFoCFzGlD8eXAW4BfxAJAeNgxAEWBTIgEbdWxzHCBhG+JoExfxHBFBcCMQbmRp8HggRDoa
mx2RJjAY8R5jCkABACFLGjVJTVDYT1JUBfARMGMfIhtl6EkgdwhgbBjgB0AlAeEJcHBocmEdARpi
IYAeeAVAAQAE9B8xIG9mNRb9LiRASRnBJ+BhcL5zFdAdcAeRHqAeGXYHQD8KUBmEGmIZsBbQBcB3
YfZ5HaADYHUmMBtlHKALUTZjLCQKsWEJwC8waCC8IkEW/y+xBCACEGwJALp3BCAuLqAi8x4YIhjy
/xxEA/AaYB9qNH8woy7/MA3oIFtDBeBdGlEdcDqe/SnQVCHDMKMbZRt1Jg8bBHQgbAQAdAZBHign
kkXYU1NDBJAhsEQpDyoV/yRAB8A4QRhRLZEaYR0BCsD9FuB1ETAY4xpuI2AcIAEA9xtAIYBGsm01
0ANhQ48qSAsbdBHxAEtQHgBwAAEAAAAsAAAATEFTVCBDQUxMOmRyYWZ0LWlldGYtcGtpeC10aW1l
LXN0YW1wLTA1LnR4dAACAXEAAQAAABsAAAABv278hkvoJhUH2ukR052CAFCLXrv0A2/1/yAAAwAu
AAAAAAALACsAAAAAAAsAAgABAAAAHgBCEAEAAAAdAAAAPDM4OUFBQTlELkZGMEE0QjE4QGJ1bGwu
bmV0PgAAAAADAP0/5AQAAEAAOQCwaLAayny/AQMA8T8JBAAAHgAxQAEAAAAIAAAAQzc5OTg3OAAD
ABpAAAAAAB4AMEABAAAACAAAAEM3OTk4NzgAAwAZQAAAAAADACYAAAAAAAMANgAAAAAAAwCAEP//
//8LAPIQAQAAAAIBRwABAAAAPAAAAGM9QVU7YT10ZWxlbWVtbztwPWNvcnBtYWlsO2w9TlRNU0cw
MTMxLTAwMDIyMjAwMTY0NlotMTQ4MTMxAAIB+T8BAAAATgAAAAAAAADcp0DIwEIQGrS5CAArL+GC
AQAAAAAAAAAvTz1URUxTVFJBL09VPVZJQyBNT05BU0gvQ049UkVDSVBJRU5UUy9DTj1DNzk5ODc4
AAAAHgD4PwEAAAAQAAAATWFuZ2VyLCBKYW1lcyBIAB4AOEABAAAACAAAAEM3OTk4NzgAAgH7PwEA
AABOAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVRFTFNUUkEvT1U9VklDIE1PTkFT
SC9DTj1SRUNJUElFTlRTL0NOPUM3OTk4NzgAAAAeAPo/AQAAABAAAABNYW5nZXIsIEphbWVzIEgA
HgA5QAEAAAAIAAAAQzc5OTg3OABAAAcw0PKmGsp8vwFAAAgwSA8cG8p8vwEeAD0AAQAAAAUAAABS
RTogAAAAAB4AHQ4BAAAAMQAAAFRpbWVzdGFtcDogMDU6IExBU1QgQ0FMTCAtIGVkaXRvcmlhbCBj
b3JyZWN0aW9ucwAAAAAeADUQAQAAADMAAAA8NzMzODg4NTdBNjk1RDMxMTk3RUYwMDUwOEIwOEYy
OTg4QTNBRjJATlRNU0cwMTMxPgAACwApAAAAAAALACMAAAAAAAMABhBcHBChAwAHEHMCAAADABAQ
AAAAAAMAERABAAAAHgAIEAEAAABlAAAAVEhFVElNRVNUQU1QVE9LRU5JU05FVkVSREVGSU5FRElO
QVNOMSxOT1RFVkVOSU5USEVBU04xTU9EVUxFQUREVE8yNDJSRVNQT05TRUZPUk1BVCxBQk9WRVNJ
R05FRERBVEFERQAAAAACAX8AAQAAADMAAAA8NzMzODg4NTdBNjk1RDMxMTk3RUYwMDUwOEIwOEYy
OTg4QTNBRjJATlRNU0cwMTMxPgAArLo=

------_=_NextPart_000_01BF7CCA.1B1C0F48--


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29915 for <[e-mail]>; Mon, 21 Feb 2000 14:32:13 -0800 (PST)
Received: from ctex01.us.cybertrust.com (ctex01.us.cybertrust.com [192.233.30.4]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03106 for <[e-mail]>; Mon, 21 Feb 2000 17:36:09 -0500 (EST)
Received: by ctex01.us.cybertrust.com with Internet Mail Service (5.5.2650.21) id <DF6Z0GZF>; Mon, 21 Feb 2000 17:36:42 -0500
Message-ID: <[e-mail]>
From: "Meggison, Tim" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Cert chain validation
Date: Mon, 21 Feb 2000 17:36:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Suppose I have a certificate chain consisting of a Root, a CA and a User
certificate.

The policy extension in the Root certificate contains one oid of 1.2.4.
The policy extension in the CA certificate contains one oid of 1.2.4.
The policy extension in the User certificate contains one oid of 1.2.4.1.

Assuming all other data is valid, is this a valid certificate chain?

It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
would determine that this certificate path is invalid.  And the way to
correct it would be to add a policy mapping to the CA certificate for the
oid 1.2.4.1.  

Is the policy mapping necessary  in a closed-community, if the Relying Party
trusts all certs issued with a policy oid of 1.2.4 and all certs issued with
a policy oid of 1.2.4.1?


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21088 for <[e-mail]>; Mon, 21 Feb 2000 08:38:23 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA01891; Mon, 21 Feb 2000 17:45:28 +0100
Received: by HYDRA with Microsoft Mail id <01BF7C91.C7637770@HYDRA>; Mon, 21 Feb 2000 17:33:34 +0100
Message-ID: <01BF7C91.C7637770@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Mon, 21 Feb 2000 17:33:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Paul,

>Ouch.

>The situation we started from is that there were two ways of
>interpreting a particular attribute.  The new situation you're
>pointing to is to increase that number from 2 to N.  I think that's a
>large step in the wrong direction.

Actually Denis proposal (which is exactly what I want to achieve with QC++) shows
a possible way to introduce a GENERIC mechanism that can be AUTOMATICALLY
deciphered (up to the level where the unmistakable identity is revealed) by RP software.
It gives N possibilities nut does not complicate RP software any more than any other extension

<snip>

Anders




Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19040 for <[e-mail]>; Mon, 21 Feb 2000 07:39:36 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQidji23148; Mon, 21 Feb 2000 15:43:18 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05602; Mon, 21 Feb 00 10:40:28 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA28870; Mon, 21 Feb 2000 10:43:16 -0500
Date: Mon, 21 Feb 2000 10:43:16 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Straw Poll: SerialNumber definition
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Denis" == Denis Pinkas <[e-mail]> writes:

 Denis> As David Kemp noticed it there are two ways to use additional
 Denis> RDN attributes:

 Denis> 1) as a disambiguator,

 Denis> Originally the idea was to add a disambiguator only in the
 Denis> case where two certificates, without the disambiguator, would
 Denis> contain identical DNs.

 Denis> 2) as a static identifier.

 Denis> Originally the idea was to use the static identifier without
 Denis> using the other DN components, which meant that the static
 Denis> identifier was sufficient to identify an individual.

 Denis> The first case means that *all* the components of the DN are
 Denis> used in conjunction with the dnq (DN Qualifier), while the
 Denis> second means that *none* of the components of the DN are used
 Denis> in conjunction with the dnq (DN Qualifier).

 Denis> In addition to these two extremes (all versus none), there is
 Denis> a number of variations where the dnq (DN Qualifier) does not
 Denis> apply to all or none, but to *some* of the components of the
 Denis> DN. This would solve other concerns raised on that thread.

Ouch.

The situation we started from is that there were two ways of
interpreting a particular attribute.  The new situation you're
pointing to is to increase that number from 2 to N.  I think that's a
large step in the wrong direction.

The problem with many standards is that they have too many options,
not too few.  Adding more stuff for the purpose of adding N-2 new
options is not a good thing at all, in my view.

	paul


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA16089 for <[e-mail]>; Mon, 21 Feb 2000 04:32:53 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA23580; Mon, 21 Feb 2000 13:36:39 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 21 Feb 2000 13:36:38 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA10069; Mon, 21 Feb 2000 13:36:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA00307; Mon, 21 Feb 2000 13:36:37 +0100 (MET)
Date: Mon, 21 Feb 2000 13:36:37 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Cc: [e-mail]

> 
> The IETF draft defines the TimeStampToken datatype as a CMS SignedData
> construct, where the TSTInfo structure is wrapped inside the CMS
> structure.  CMS SignedData constructs can be used in two different
> ways, however; as an encapsulation and as an external signature.  The
> encapsulation mode means the data upon which the signature is computed
> is wrapped inside the CMS structure, whereas the external signature
> mode leaves the data external to the CMS structure.  Both modes provide
> equivalent security, both are directly supported and specified within
> the CMS specification [RFC 2630, page 9].
> 
> The ISO proposal is to simply use the CMS construct as an external
> signature rather than as an encapsulation.  The ISO proposal thus
> defines the 'TimeStampToken' data type as follows:
> 
> TimeStampToken ::= SEQUENCE {
>         tspData         TSTInfo,
>         tspSignature    OCTET STRING }
> 
> The CMS SignedData construct used as an external signature is
> DER-encoded in the tspSignature field.  In effect both proposals
> accomplish the same thing; the TSTInfo structure is signed, and the
> signature information is encapsulated in a CMS SignedData construct.

The inconvenience is to have 'yet another structure': I do not see a
real advantage to replace the CMS SignedData with the structure above.
have a CMS document at the top level has several advantadges; you
might use encryption around it you still have a 'document'.

It might be worth to look at the structure for the Digested-Data
content-Type.  

   The following object identifier identifies the digested-data content
   type:

      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

   The digested-data content type shall have ASN.1 type DigestedData:

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,
        digest Digest }

      Digest ::= OCTET STRING

and use this in the case when you 'Digest' corresponds to
something defined by a mecanism. 

Have fun.
Peter Sylvester


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14997 for <[e-mail]>; Mon, 21 Feb 2000 03:39:13 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA18561; Mon, 21 Feb 2000 11:43:04 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma018529; Mon, 21 Feb 00 11:42:43 GMT
Received: from baltimore.ie (lease173-21.baltimore.ie [192.168.21.173]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA31535; Mon, 21 Feb 2000 11:42:42 GMT
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2000 11:34:47 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
CC: xme <[e-mail]>, RussHousley <[e-mail]>
Subject: AC profile
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

I'currently working on the next version of the AC profile
(which I hope to get to last call after Adelaide). There
were a few issues from Washington that I said I'd bring to
the list before we issue the new I-D:

- Do we need to support chains of ACs? 

I'd say the answer is "no, not in this version". I think its
reasonable to take the position that very few people will 
want this (and even fewer in the near future) so that anyone 
who they can write a new I-D to extend the profile for that 
case. I think this was the sense of the room in Washington.

- What to do about AAControls? 

I'm not so sure what's right here & would like some input 
(if you don't know what this is about, read the section 
and maybe look at the slides from Washington). My preference
today (it changes often:-) is to leave it in pretty much 
as is, but move it to section 7, so that it becomes optional 
to implement.

Other than that, I also need to bring up the recovation
schemes, but I'll wait 'till I've got text that's in 
synch with the latest X.509 DAM before bringing that to
the list.

Regards,
Stephen.

PS: For those of you who've already sent me comments, 
I'm going through them now, so no need to resend.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11302 for <[e-mail]>; Mon, 21 Feb 2000 02:12:40 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id LAA01671; Mon, 21 Feb 2000 11:20:02 +0100
Received: by HYDRA with Microsoft Mail id <01BF7C5B.EF684740@HYDRA>; Mon, 21 Feb 2000 11:08:09 +0100
Message-ID: <01BF7C5B.EF684740@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Mon, 21 Feb 2000 11:08:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

<snip>

>All concepts could nicely co-exist if we could find a way to say on
>*which* components of the DN the dnq (DN Qualifier) would apply.
>Rather than leaving the interpretation to an (unprocessable)
>Certificate Policy OID, we should define a way to express which
>components of the RDN should be associated with the dnq to make the
>name unmistakable and *permanently* unique. 

>In this way RPs could use this minimum structure in their ACLs. Note
>that at the same time this would define the rule to compare two
>certificates, i.e. know whether they bear the same minimum permanent
>structure and hence refer to the same individual or not.

This sounds like MUSIC in my ears!

<snip>

Anders




Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10939 for <[e-mail]>; Mon, 21 Feb 2000 01:54:16 -0800 (PST)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA104754 for <[e-mail]>; Mon, 21 Feb 2000 10:57:38 +0100
Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA27538 for <[e-mail]>; Mon, 21 Feb 2000 10:57:37 +0100
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C125688C.0036B37A ; Mon, 21 Feb 2000 10:57:28 +0100
X-Lotus-FromDomain: IBMIL@IBMDE
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2000 11:57:25 +0200
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10658 for <[e-mail]>; Mon, 21 Feb 2000 01:47:04 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id KAA22054; Mon, 21 Feb 2000 10:49:30 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2000 10:49:27 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: "[e-mail]" <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As David Kemp noticed it there are two ways to use additional RDN
attributes:

1) as a disambiguator,

Originally the idea was to add a disambiguator only in the case
where two certificates, without the disambiguator, would contain
identical DNs.

2) as a static identifier.

Originally the idea was to use the static identifier without using
the other DN components, which meant that the static identifier was
sufficient to identify an individual.

The first case means that *all* the components of the DN are used in
conjunction with the dnq (DN Qualifier), while the second means that
*none* of the components of the DN are used in conjunction with the
dnq (DN Qualifier).

In addition to these two extremes (all versus none), there is a
number of variations where the dnq (DN Qualifier) does not apply to
all or none, but to *some* of the components of the DN. This would
solve other concerns raised on that thread.

All concepts could nicely co-exist if we could find a way to say on
*which* components of the DN the dnq (DN Qualifier) would apply.
Rather than leaving the interpretation to an (unprocessable)
Certificate Policy OID, we should define a way to express which
components of the RDN should be associated with the dnq to make the
name unmistakable and *permanently* unique. 

In this way RPs could use this minimum structure in their ACLs. Note
that at the same time this would define the rule to compare two
certificates, i.e. know whether they bear the same minimum permanent
structure and hence refer to the same individual or not.

Let me make a proposal to explain the idea a little bit more. A DN
is an ordered sequence of RDN Attributes. If we added a new
attribute, it could say which components of the ordered sequence of
RDN Attributes shall be used with the dnq to make the name not only
"unmistakable" bu also permanently unique. This could be, for
example, a bit string. If bit 3 is on, this means that the third
component of the DN has to be used with the dnq to make the whole DN
unmistakable and unique *over time* for a given CA. 

This allows to know how the dnq and other DN components are to be
interpreted during the decoding of the unmistakable identity, in a
fully processable way. The big advantage is that we then have a way
to automatically process names, rather than to rely on unprocessable
Policy OIDs.

Denis


Received: from mail.hy.hn.cninfo.net (nsmail@[202.103.112.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08487 for <[e-mail]>; Sun, 20 Feb 2000 23:15:44 -0800 (PST)
Received: from lilei ([202.103.127.45]) by mail.hy.hn.cninfo.net (Netscape Messaging Server 3.01)  with SMTP id AAA4287 for <[e-mail]>; Mon, 21 Feb 2000 15:20:33 +0800
Message-ID: <014001bf7c3c$27c272c0$[e-mail]>
Reply-To: "leili" <[e-mail]>
From: "lilei" <[e-mail]>
To: <[e-mail]>
Subject: unsubscript
Date: Mon, 21 Feb 2000 15:20:23 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01BF7C7F.2C23D5A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_013D_01BF7C7F.2C23D5A0
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable



------=_NextPart_000_013D_01BF7C7F.2C23D5A0
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Dhz-gb-2312" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_013D_01BF7C7F.2C23D5A0--



Received: from Mars.csc.neu.edu.cn (mars.csc.neu.edu.cn [202.118.3.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07230 for <[e-mail]>; Sun, 20 Feb 2000 21:24:34 -0800 (PST)
Received: from aries.synet.edu.cn (beaver.csc.neu.edu.cn [202.118.3.59]) by Mars.csc.neu.edu.cn (8.9.1/8.9.1) with ESMTP id NAA27792 for <[e-mail]>; Mon, 21 Feb 2000 13:32:23 +0800 (CST)
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2000 13:33:35 +0800
From: jinhy <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en,zh-CN
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscript
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02089 for <[e-mail]>; Sun, 20 Feb 2000 19:08:25 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA438976 for <[e-mail]>; Sun, 20 Feb 2000 22:11:02 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id WAA132318 for <[e-mail]>; Sun, 20 Feb 2000 22:12:15 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525688C.001196B6 ; Sun, 20 Feb 2000 22:12:06 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 20 Feb 2000 22:11:34 -0500
Subject: Re: Straw Poll: SerialNumber definition
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     This question may be split into several separate ones.  First, should
there exist standard attributes with the following characteristics: 1)
affiliation ID, typically an employee ID, a membership ID, or a customer
number, assigned by either the organization in the DN containing it or one
of the organizational units in that DN and must be unique at the time of
its assignment (not necessarily for all time); 2) DN Disambiguator, added
to at least one of two otherwise identical DN's by a directory
administrator or a CA for the purpose of breaking an ambiguity; 3) national
ID, which is similar to affiliation ID but assigned by the country in the
DN?  Second, if defined should they be permitted in DN's?  Third, should
any existing standard X.520 attributes be mapped onto any of these three,
which would require some amendments to their definitions in X.520?  Fourth,
for any attributes permitted in DN's, are they permitted to appear in the
same RDN with a CN or Surname attribute?    The suggestions which have been
made which involve "yes" for the third question are that serial number be
interpreted for persons (for which it is currently undefined) as
affiliation ID or national ID above, and that the clause requiring that DN
Qualifier have the same value for all entries in a single DSA be repealed,
and then DN Qualifier be used as one of the three possibilities above.

      I know of no real argument that either affiliation ID or DN
Disambiguator is an inappropriate or undesirable attribute, and the only
question about national ID is whether it is desirable from a privacy
standpoint.  National policy might well ban its use in some countries, and
ban its use as a naming attribute in others.  I am one of those who have
suggested that serial number's definition be amended and that it be used
for affiliation ID.  I also think that any of these attributes should be
permitted in the same RDN as personal name attributes if they are permitted
in names at all.  Some of the responses in this poll have left me unsure as
to how a relying party could tell whether the proposed use of serial number
or DN Qualifier was expected to be unique on a country basis or on an
organization basis.
     There are two further questions which arise if one or both of the ID's
above are defined as attributes or mapped to existing ones.  Should there
be separate attributes for variants of either or both of the ID's above
which imply that the ID is expected to be unique over very long periods of
time (multiple centuries for national ID), so that a DN containing the ID
but no personal name is a long-lived identity?  Also, should affiliation ID
above be further subdivided according to the nature of the affiliation
(employee, member, customer, etc.)?

          Tom Gindin

P.S. The opinions above are mine, and not necessarily those of my employer.




Received: from c004.sfo.cp.net (c004-h005.c004.sfo.cp.net [209.228.14.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24544 for <[e-mail]>; Sun, 20 Feb 2000 13:36:52 -0800 (PST)
Received: (cpmta 17250 invoked from network); 20 Feb 2000 13:40:13 -0800
Received: from msn-62.au1.du.uunet.de (HELO tuvit.net) (149.229.132.62) by smtp.tuvit.net with SMTP; 20 Feb 2000 13:40:13 -0800
X-Sent: 20 Feb 2000 21:40:13 GMT
Message-ID: <[e-mail]>
Date: Sun, 20 Feb 2000 15:42:12 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------A23E26B45D5DF83AA08D4D91"

This is a multi-part message in MIME format.
--------------A23E26B45D5DF83AA08D4D91
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Denis,

The ISO working group would like to thank the members of the IETF
working group for their efforts toward producing an interoperable
timestamping standard.  We are pleased to incorporate aspects of the
recent IETF proposal into our work in the interests of developing a
truly interoperable standard.

1. Request message

We concur with the IETF proposal for making the 'mechanism' field of
the interoperable request message an optional field, placed in the
structure at a position selected by the authors of the IETF draft
document.  We feel the selection of a default value for the field is a
matter of local policy and hence should be determined by the local
policy statement of the TSA.

2. Error codes

We concur with the IETF proposal for setting aside a range of error
codes for future use by the SC 27 group.  At this time only one
additional code is anticipated, however setting aside a quantity of
error codes for use by SC 27 is a quite reasonable approach.

3. Reply message

The latest IETF proposal suggests that replies generated by the
systems are quite different, and hence cannot be aligned.  The ISO
working group would respectfully disagree here, as the replies are
actually quite similar, and we believe they can be aligned with a
minimum of effort.

The timestamp information returned by both proposals is actually
identical, as the ISO proposal has chosen to adopt the IETF TSTInfo
structure, with an optional mechanism field corresponding to the one
agreed to above.  Since both proposals use the same TSTInfo structure,
time values are interoperable, hash codes and algorithms are
interoperable, policy and mechanism identifiers are interoperable.
Both proposals encapsulate the TSTInfo structure in the TimeStampToken
datatype; the only remaining difference is in syntax of that datatype.

The IETF draft defines the TimeStampToken datatype as a CMS SignedData
construct, where the TSTInfo structure is wrapped inside the CMS
structure.  CMS SignedData constructs can be used in two different
ways, however; as an encapsulation and as an external signature.  The
encapsulation mode means the data upon which the signature is computed
is wrapped inside the CMS structure, whereas the external signature
mode leaves the data external to the CMS structure.  Both modes provide
equivalent security, both are directly supported and specified within
the CMS specification [RFC 2630, page 9].

The ISO proposal is to simply use the CMS construct as an external
signature rather than as an encapsulation.  The ISO proposal thus
defines the 'TimeStampToken' data type as follows:

TimeStampToken ::= SEQUENCE {
        tspData         TSTInfo,
        tspSignature    OCTET STRING }

The CMS SignedData construct used as an external signature is
DER-encoded in the tspSignature field.  In effect both proposals
accomplish the same thing; the TSTInfo structure is signed, and the
signature information is encapsulated in a CMS SignedData construct.

Defining the TimeStampToken type as proposed above allows both IETF
and ISO mechanisms to generate fully interoperable tokens, while in
addition allows the ISO to develop those additional mechanisms it
has identified for support.

On a final note, aligning the standards as proposed above has the
added benefit of making the token embedding technique detailed in
Annex A of the IETF draft also completely interoperable.  No changes
to that Annex are required.
--------------A23E26B45D5DF83AA08D4D91
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------A23E26B45D5DF83AA08D4D91--



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07738 for <[e-mail]>; Sat, 19 Feb 2000 01:23:44 -0800 (PST)
Received: from mega (t4o69p116.telia.com [62.20.145.236]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id KAA15946; Sat, 19 Feb 2000 10:30:53 +0100
Message-ID: <005a01bf7ac3$6484a810$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>
Subject: QC++ BOF suggestion
Date: Sat, 19 Feb 2000 10:23:03 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA07742

In spite of the delayed QC draft, Qualified Certificates are in production since quite a while. 

I wonder if there is any sentiment for starting a new QC++ work that is targeted
at future QCs?

Why?
Well, as I hope that has shined through my frequent postings I do not believe that
a draft that contains a huge number of loose ends is suitable for MECHANICAL
digestion by RPs.   The certificate comparision section telling that it must
be performed with "care" is a very notable example of that. 

A prime goal of QC++ is that you must be able to compare certificates and that
different DN components may be assigned precedence in a way that is a de-facto
standard.  QC++ supports these rules within the certificate itself.

QC-03's optional private CP OIDs and QC statements cannot be added to an
existing customer base so they really just makes the process even harder.  I.e. is 
there an CP OID in the cert and if it is not, is that an error etc. etc.

The main target for QC++ are public PKIs and commercial TTPs, but long-term all
QC-issuers will gain from the software framwork that will support this.

Anders Rundgren




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05665 for <[e-mail]>; Sat, 19 Feb 2000 00:24:17 -0800 (PST)
Received: from mega (t4o69p54.telia.com [62.20.145.174]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA15295; Sat, 19 Feb 2000 09:31:30 +0100
Message-ID: <003401bf7abb$17e85b80$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "Charles Moore" <[e-mail]>, <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Sat, 19 Feb 2000 09:24:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA05666

Charles,

>I can send you some example of CP qualifiers that we have use din closed
>communities to do some of the things you are looking for...


Don't do that because as I say, the number of rules to MANDATORY DECLARE for a QC CA
(in plain writing, NOT as private OIDs) can't be that great.  To solve the "identity crisis" that is.

It could/should be 

   Naming domain
      "Citizen of Guatemala"
      "VeriSign Qualified Certificate Domain"
      "Telia Mobitel"
      "IBM Corp."
      "Utah Driving License Register"

   How subject DNs are to be interpreted to form the unmistakable identity (*)
      "All DN components"
      "[SN only],  CN contains the name of the subject at the time of issuing"
      "[SN + OU], CN contains the name of the subject at the time of issuing"

  How the CA reuses unmistakable identities (UI)
      "Never reuses an UI to another entity"
      "May reuse an UI to another entity"      ; Should NOT be alllowed for a QC IMO
   

(*) Strictly X.500 all QC-variants using the entire DN form an unmistakable identity
but that the THEORETICAL model.   The PRACTICAL model may go a few steps
further.  And does so in a number of large, potentially very important PKIs.

Anders



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05201 for <[e-mail]>; Fri, 18 Feb 2000 14:39:45 -0800 (PST)
Received: from mega (t1o69p49.telia.com [62.20.144.49]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id XAA08870; Fri, 18 Feb 2000 23:46:53 +0100
Message-ID: <00a301bf7a69$6b59df70$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 23:39:37 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA05202

Stefan,

<snip>

>Let me give you one reason/example why we can't require serialNumber to be
>unique for a person.


This is very important: I do not REQUIRED that serialNumbers should be unique
for a person.  I really think they should but my world is not smashed into pieces if I don't get
it.  Such a solution would IMO require a reinstated dnQualifier as well.

I have though requested simple (as I am only intereted in real-world stuff you know) additions
to QC CP-requirements so that a conforming CA must DECLARE a few VERY important things like

   Naming domain.

   How serialNumbers and other DN components are to be interpreted during the decoding of the
   unmistakable identity and that this interpretation may or may not be X500-friendly (using DN as a whole).

   State the reuse of the extracted identity over time versus entities.

With a fairly limited set of rules like that you can design apps with confidence and compare certs
or SNs or whatever in a defined way.

To use private OIDs for such things is IMO a vaste of time as you have to do this separately
for each CA as the OIDs are not standardized.  And then there is the default-interpretion-rule-trauma.

Note: No new bits and bytes.  Just rules will do the trick.


<snip>

Anders




Received: from mail.phenix.com.au (fwuser@[203.37.242.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03849 for <[e-mail]>; Fri, 18 Feb 2000 13:47:21 -0800 (PST)
Message-ID: <1115E3FF8E9CD211A07C006008C2045001C602@MAIL>
From: Charles Moore <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Anders Rundgren <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: SEIS:  Stray Poll: SerialNumber definition
Date: Sat, 19 Feb 2000 07:50:55 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

My personal preference was for a new attraibute, but given that serial
number is wrong..., dnq was in a previous draft, and it appears that there
is consensus that your usage of dnq is actually valid....
Then your suggestion seems a resonable way forward...


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Saturday, 19 February 2000 0:04
To: Anders Rundgren; [e-mail]; [e-mail];
[e-mail]
Subject: SEIS: Stray Poll: SerialNumber definition


Reinstate dnQualifier!
It is more "user friendly" when discussing certificate contents with
non-technical people. In 
the wake of the EU-directive this will definitively be the case that a much
larger community 
than PKIX will address digital certificate format and content. Nobody wants
to think of 
themselves as "serial number". Besides, as A. Rudgren points out, the
dnQualifier has been 
(mis)used for unique number by many (us in Norway, e.g.).
Best regards,
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [e-mail]


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03516 for <[e-mail]>; Fri, 18 Feb 2000 13:43:00 -0800 (PST)
Received: from Santesson (lon-qbu-bsi-vty25.as.wcom.net [195.232.123.25]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id WAA27702; Fri, 18 Feb 2000 22:46:40 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 22:45:50 +0100
Message-ID: <000001bf7a59$86c13430$197be8c3@Santesson>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <01BF7A34.CFE6CA00@HYDRA>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Anders,

As you may see if you read the specified section 3.2.5.1, there are no
speciffic OID:s for Swedish civic registration number etc, but there is a
defined place to put such OID:s if they are defined within a local
community.

I also would like to point out the solution mentioned by David Kemp, where
you can use a policy OID with a similar effect.

Let me give you one reason/example why we can't require serialNumber to be
unique for a person.

That is the case when the serialNumber contains an employee number or
similar code, which is unique only in combination with the organization
name.

When we have:

CN="Joe Black"
O="IBM"
SN="1234"

and

CN="Joe Black"
O="SUN"
SN="1234"

Well, is this the same person Joe Black working in two different
organizations or is this two persons with the same name and accidently also
having the same employee number.

Well, I sure can't tell and most systems would simply not care. But I'm sure
that our scheme in QC must recognize both cases as valid. Consequently the
exact sematics mut be allowed to be provided by other means (policy OID
and/or qcStatements extension)

/Stefan

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Friday, February 18, 2000 5:23 PM
To: [e-mail]; [e-mail]; 'Stefan Santesson'
Subject: RE: Stray Poll: SerialNumber definition


Stefan,

 >This is all wrong.

>Section 3.2.5.1 gives you all the tools you need to explicitly define the
>nature of the content in the serialNumber attribute.

OK, where can I find the list of defined OIDs expressing how to interpret
serialNumber
in the really impressing number of ways you provide in your posting?

Because, if a CA have to define these by itself and communicate this to all
potential
RPs it is really the CA that is setting the standard.  I don't buy into
that.

Another problem is that the absence of a clear default-interpretation of
serialNumber
semantics.

Nice list though!

/Anders

>And you can do more than just identify that the information is unique per
>user, you can also identify in what manner the information is unique (World
>wide unique, unique per certificate in the issuers domain, unique per
>subject in the issuers domain, unique per subject in the specified country
>etc).

>You can even define exactly the nature of the content (Swedish civic
>registration code, Utah drivers license number, etc...)

>And more to it, you can name the registration authority (Swedish tax
>authority, Utah drivers license registry, etc...)

>All of this you already have in QC 03, what else do you need ?


>/Stefan



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29697 for <[e-mail]>; Fri, 18 Feb 2000 12:02:06 -0800 (PST)
Received: from mega (t4o69p8.telia.com [62.20.145.128]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id VAA05999; Fri, 18 Feb 2000 21:09:07 +0100
Message-ID: <004c01bf7a53$612e4600$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: Straw (was Stray) Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 21:01:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA29698

David,
Straw? Pardon my language :-(

>Automated RPs must have:
>
>1) Domain-specific knowledge required to interpret the name schema,
>   to include the meaning of the SN attribute, if present.
>   RPs aren't usually comparing one cert with another, they are
>   allowing the user who has presented a cert to do something useful.
>   If I am filing a tax return, I must identify myself with something
>   meaningful to the tax collection agency.


I don't disagree.   But there is no requirement on a QC-conformat CA to specify anything
in the CP to aid developers.  Regarding RPs comparing certs:  In the Swedish system you
don't even have to compare certs as it is sufficient to know the subjects SN!  And of course
recongnizing that the issuer is one of the trusted CAs issuing such certificates..

>2) Knowledge that a cert belongs to the RP's recognized domain(s).
>   "Someone" (an industry consortium, a standards body, a government
>   agency, a self-appointed policy authority such as a public CA, etc)
>   has to define what their domain means and register an OID to identify
>   the domain.

That is a possibility but who is handling this registration?  I believe that it is enough
that the CA specifies domain in the CP.  Sort of MINIMUM requirement.

<snip>

>Who originally creates the CP and the naming convention is outside the
>scope of the QC profile.  All that matters is that the CA and the RP
>agree on the meaning of a domain and can mechanically determine that a
>cert belongs to the domain.

Hum, there may be thousands of RPs 'listening' to a certain CA.   This thinking does
not scale.  I.e. this MUST be declared by the CA.  In some way.


>One problem with insisting on two different RDN attributes for
>disambiguator and static identifier is that different RPs (or the
>same RP for different purposes) may treat the identical information
>differently.  If there are two certs:
>
>   cn=Pamela Jones + sn=200
>   cn=Pamela Anderson + sn=200
>
>the SN may well identify a single person, but an RP may wish to maintain
>one set of accounts/privileges/attributes/statistics which are segregated
>by CN, and another set which apply to the person regardless of CN.
>For some purposes the certs refer to two different entities; for other
>purposes they refer to a single entity.
>

I must admit that I don't understand this.  To me it is the CA and not the RP that sets
the policy.  If CA = RP (eating its own crap) there is never any need to carry any kind of
additional information in the cert as such info is extracted from various sources based
on authentication.  In case the RP really needs signed/certified additional information,
ACs or Thin PKI solve this.

Anders




Received: from sac0047.ac.correiosnet.int ([200.252.60.139]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27272 for <[e-mail]>; Fri, 18 Feb 2000 10:58:50 -0800 (PST)
Received: by sac0047.ac.correiosnet.int with Internet Mail Service (5.5.2650.21) id <FD6Y8RXZ>; Fri, 18 Feb 2000 17:00:31 -0200
Message-ID: <[e-mail]>
From: Souza Neto <[e-mail]>
To: [e-mail]
Subject: SUBSCRIBE
Date: Fri, 18 Feb 2000 17:00:25 -0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

SUBSCRIBE



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26634 for <[e-mail]>; Fri, 18 Feb 2000 10:48:21 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA04556 for <[e-mail]>; Fri, 18 Feb 2000 13:52:29 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA04552 for <[e-mail]>; Fri, 18 Feb 2000 13:52:29 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA11735 for <[e-mail]>; Fri, 18 Feb 2000 13:52:21 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA15935 for <[e-mail]>; Fri, 18 Feb 2000 13:49:31 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 18 Feb 2000 13:49:31 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Straw (was Stray) Poll: SerialNumber definition
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ioKX6PB0GemJYF7s0PUw/A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Anders Rundgren <[e-mail]>
> 
> OK, where can I find the list of defined OIDs expressing how to interpret 
serialNumber
> in the really impressing number of ways you provide in your posting?
> 
> Because, if a CA have to define these by itself and communicate this to all 
potential
> RPs it is really the CA that is setting the standard.  I don't buy into that.


Anders,

Automated RPs must have:

1) Domain-specific knowledge required to interpret the name schema,
   to include the meaning of the SN attribute, if present.
   RPs aren't usually comparing one cert with another, they are
   allowing the user who has presented a cert to do something useful.
   If I am filing a tax return, I must identify myself with something
   meaningful to the tax collection agency.

2) Knowledge that a cert belongs to the RP's recognized domain(s).
   "Someone" (an industry consortium, a standards body, a government
   agency, a self-appointed policy authority such as a public CA, etc)
   has to define what their domain means and register an OID to identify
   the domain.  In the simplest case, the OID would go in the Certificate
   Policies extension, not requiring the QC Statements extension.  The CP
   would state that the SN attribute contains a taxpayer ID number, and
   the tax collecting RP would only trust CAs known to follow the CP
   (by populating SN as agreed in certs with that CP OID).

Who originally creates the CP and the naming convention is outside the
scope of the QC profile.  All that matters is that the CA and the RP
agree on the meaning of a domain and can mechanically determine that a
cert belongs to the domain.


One problem with insisting on two different RDN attributes for
disambiguator and static identifier is that different RPs (or the
same RP for different purposes) may treat the identical information
differently.  If there are two certs:

   cn=Pamela Jones + sn=200
   cn=Pamela Anderson + sn=200

the SN may well identify a single person, but an RP may wish to maintain
one set of accounts/privileges/attributes/statistics which are segregated
by CN, and another set which apply to the person regardless of CN.
For some purposes the certs refer to two different entities; for other
purposes they refer to a single entity.


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


Stefan,

I can't tell from section 3.2 which extensions MUST be present in a QC
and which are optional.  For example, "The certificate policies extension
SHALL contain the identifier of at least one certificate policy ...",
but it's not unambiguously clear (to me) that the CP extension SHALL
be present in every QC.

Could the required/optional status of each of the five extensions be
stated in section 3.2?

Dave Kemp



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22917 for <[e-mail]>; Fri, 18 Feb 2000 08:29:29 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA32764; Fri, 18 Feb 2000 17:36:36 +0100
Received: by HYDRA with Microsoft Mail id <01BF7A35.0AC7B9E0@HYDRA>; Fri, 18 Feb 2000 17:24:42 +0100
Message-ID: <01BF7A35.0AC7B9E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 17:24:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

<snip>
>> serialNumber DN Disambiguer usage:
>> 
>>         cn=John Doe, sn=456
>>         cn=John Doe, sn=200
>>         cn=Pamela Anderson, sn=200
>> 
>> Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
>> The three certificates MAY (or may not) denote different persons.

>This seems simple but does not work. :-(  In a DN, some AVAs are
>long term invariants while some others are not. What would be needed
>is to qualify a subset of the AVAs that is an invariant. For
>example, an OU in some cases may change over time and there is no
>wish to re-issue a certificate when the change occurs. So it would
>be nice to keep e.g. cn=John Doe, sn=200, even if the OU has
>changed.

You are referring to a non-real-world problem looking for an X.500 solution.
In the REAL world you use employee IDs (if they are organization-wide) or
you have to issue a new certificate.

<snip>
>> Anticipated ID algorithm: Only SN is used to identify the subject.  

>Ah ! Ah! It seems that we are reinventing the wheel. :-)

>Once upon a time, ... there used to be an X.509 v2 certificate with
>an optional field called: "SubjectUnique Identifier". Its use has
>been deprecated. However what is described here matches with the
>intended usage of that field. 

AFAIK It was deprecated due to BITSTRING syntax and (in a very odd way)
partially replaced by serialNumber.  This is used in huge PKIs as UID.

<snip>

Anders



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22685 for <[e-mail]>; Fri, 18 Feb 2000 08:27:49 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA32695; Fri, 18 Feb 2000 17:35:00 +0100
Received: by HYDRA with Microsoft Mail id <01BF7A34.CFE6CA00@HYDRA>; Fri, 18 Feb 2000 17:23:03 +0100
Message-ID: <01BF7A34.CFE6CA00@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 17:23:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

 >This is all wrong.

>Section 3.2.5.1 gives you all the tools you need to explicitly define the
>nature of the content in the serialNumber attribute.

OK, where can I find the list of defined OIDs expressing how to interpret serialNumber
in the really impressing number of ways you provide in your posting?

Because, if a CA have to define these by itself and communicate this to all potential
RPs it is really the CA that is setting the standard.  I don't buy into that.

Another problem is that the absence of a clear default-interpretation of serialNumber
semantics.

Nice list though!

/Anders

>And you can do more than just identify that the information is unique per
>user, you can also identify in what manner the information is unique (World
>wide unique, unique per certificate in the issuers domain, unique per
>subject in the issuers domain, unique per subject in the specified country
>etc).

>You can even define exactly the nature of the content (Swedish civic
>registration code, Utah drivers license number, etc...)

>And more to it, you can name the registration authority (Swedish tax
>authority, Utah drivers license registry, etc...)

>All of this you already have in QC 03, what else do you need ?


>/Stefan



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21021 for <[e-mail]>; Fri, 18 Feb 2000 07:56:46 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id RAA37902; Fri, 18 Feb 2000 17:00:13 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Feb 2000 16:59:55 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Re: Stray Poll: SerialNumber definition
References: <01BF7A1B.4D185850@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

I have followed some of the exchanges.

> Hi,
> The current QC-03 definition of serialNumber is ambiguous.  This
> posting is trying to find out the support for such a solution in a standard-to-be,
> targeting legally binding signatures.  The two uses of serialNumber
> are pictured by the following tables with subject DNs from three different
> certificates coming from a single CA.
> 
> serialNumber DN Disambiguer usage:
> 
>         cn=John Doe, sn=456
>         cn=John Doe, sn=200
>         cn=Pamela Anderson, sn=200
> 
> Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
> The three certificates MAY (or may not) denote different persons.

This seems simple but does not work. :-(  In a DN, some AVAs are
long term invariants while some others are not. What would be needed
is to qualify a subset of the AVAs that is an invariant. For
example, an OU in some cases may change over time and there is no
wish to re-issue a certificate when the change occurs. So it would
be nice to keep e.g. cn=John Doe, sn=200, even if the OU has
changed. We could say that in the CP. However, AFAIK, CP are not
machine processable and we have currently no way to say this. Should
we invent one ? Not sure. See the next argument. 
 
> serialNumber UID usage:
> 
>         cn=John Doe, sn=456
>         cn=John Doe, sn=200
>         cn=Pamela Anderson, sn=200
> 
> Anticipated ID algorithm: Only SN is used to identify the subject.  

Ah ! Ah! It seems that we are reinventing the wheel. :-)

Once upon a time, ... there used to be an X.509 v2 certificate with
an optional field called: "SubjectUnique Identifier". Its use has
been deprecated. However what is described here matches with the
intended usage of that field. 

Why don't we use it, instead of using something else that is not
very well named anyway (serialNumber has always been confusing with
the serialNumber from the certificate itself) ?

The SubjectUniqueIdentifier is mainly useful if the content of the
certificate is used for access control purposes. This fixed size
information can be placed in an ACL. It has to be unique for the
issuing CA, not universally unique.

This field can certainly be useful but must remain optional (all
certificates are not used for access control purposes).


> CN is used a "Friendly Name", "Information" etc.
> The two last certificates denote the same person.  John had a successful transsexual operation :-).
> Huge PKI systems are currently being deployed using this scheme.
> 
> The QC-03 draft does neither specify how serialNumber is to be interpreted, nor specify
> how a CA should could inform an RP about its use of serialNumber.
> 
> The alternatives are
> 
> 1. Keep the current definition

The name is a problem anyway.

> 2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.

CPs are not machine processable, so this does not work. However, we
shall continue to mandate the uniqueness of the DN as a whole (or of
the alternate name as a whole).

> 3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute

dnQualifier would certainly be a better name, but in the absence of
the knowledge of invariant AVAs, the benefits are minimum. The new
DN disambiguer attribute is in fact the SubjectUniqueIdentifier.

> 4. Other...

Introduce the optional field SubjectUniqueIdentifier and make it
part of QC-04.

Denis

> Anders Rundgren


Received: from isak.online.no (isak.online.no [193.212.240.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16391 for <[e-mail]>; Fri, 18 Feb 2000 06:00:04 -0800 (PST)
From: [e-mail]
Received: from gw.telemax.no by isak.telepost.no (X.400 to RFC822 Gateway); Fri, 18 Feb 2000 15:03:39 +0100
X400-Received: by mta MHNORWAY in /c=no/admd=telemax/prmd=internet/; Relayed;  18 Feb 2000 15:03:38 +0100
X400-Received: by /c=no/admd=telemax/prmd=internet/; Relayed;  18 Feb 2000 15:03:38 +0100
X400-Received: by /c=no/admd=telemax/prmd=dep/; Relayed; 18 Feb 2000 14:03:31 Z
X400-MTS-Identifier: [/c=no/admd=telemax/prmd=dep/; 11465 00/02/18 15:03]
Content-Identifier: 11465 00/02/18
Content-Return: Prohibited
X400-Content-Type: P2-1988 ( 22 )
Conversion: Allowed
Original-Encoded-Information-Types: IA5-Text
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [e-mail]
X400-Recipients: non-disclosure;
Message-Id:  <"11465 00/02/18 15:03*/c=no/admd=telemax/prmd=dep/o=aad/s=de-brisis/g=katarina/"@MHS>
In-Reply-To: <01BF7A1B.4D185850@HYDRA>
Date: 18 Feb 2000 14:03:31 Z
To: Anders Rundgren <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: SEIS:  Stray Poll: SerialNumber definition

Reinstate dnQualifier!
It is more "user friendly" when discussing certificate contents with non-technical people. In 
the wake of the EU-directive this will definitively be the case that a much larger community 
than PKIX will address digital certificate format and content. Nobody wants to think of 
themselves as "serial number". Besides, as A. Rudgren points out, the dnQualifier has been 
(mis)used for unique number by many (us in Norway, e.g.).
Best regards,
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [e-mail]


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16027 for <[e-mail]>; Fri, 18 Feb 2000 05:51:46 -0800 (PST)
Received: from bestlaptop (lon-qbu-bsf-vty117.as.wcom.net [195.232.120.117]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id OAA18404; Fri, 18 Feb 2000 14:55:18 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 15:55:45 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <[e-mail]>

Anders,

>Anders wrote:
>
> The QC-03 draft does neither specify how serialNumber is to
> be interpreted, nor specify
> how a CA should could inform an RP about its use of serialNumber.
>

This is all wrong.

Section 3.2.5.1 gives you all the tools you need to explicitly define the
nature of the content in the serialNumber attribute.

And you can do more than just identify that the information is unique per
user, you can also identify in what manner the information is unique (World
wide unique, unique per certificate in the issuers domain, unique per
subject in the issuers domain, unique per subject in the specified country
etc).

You can even define exactly the nature of the content (Swedish civic
registration code, Utah drivers license number, etc...)

And more to it, you can name the registration authority (Swedish tax
authority, Utah drivers license registry, etc...)

All of this you already have in QC 03, what else do you need ?


/Stefan



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA14950 for <[e-mail]>; Fri, 18 Feb 2000 05:25:17 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id OAA17282; Fri, 18 Feb 2000 14:32:20 +0100
Received: by HYDRA with Microsoft Mail id <01BF7A1B.4D185850@HYDRA>; Fri, 18 Feb 2000 14:20:26 +0100
Message-ID: <01BF7A1B.4D185850@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 14:20:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
The current QC-03 definition of serialNumber is ambiguous.  This
posting is trying to find out the support for such a solution in a standard-to-be,
targeting legally binding signatures.  The two uses of serialNumber
are pictured by the following tables with subject DNs from three different
certificates coming from a single CA.

serialNumber DN Disambiguer usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
The three certificates MAY (or may not) denote different persons.


serialNumber UID usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: Only SN is used to identify the subject.  CN is used a "Friendly Name", "Information" etc.
The two last certificates denote the same person.  John had a successful transsexual operation :-).
Huge PKI systems are currently being deployed using this scheme.

The QC-03 draft does neither specify how serialNumber is to be interpreted, nor specify
how a CA should could inform an RP about its use of serialNumber.

The alternatives are

1. Keep the current definition
2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.
3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute
4. Other...

Anders Rundgren



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17338 for <[e-mail]>; Thu, 17 Feb 2000 19:37:21 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA16520 for <[e-mail]>; Fri, 18 Feb 2000 14:40:28 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd3IIv5_; Fri Feb 18 14:40:12 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id OAA17557 for <[e-mail]>; Fri, 18 Feb 2000 14:40:11 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0JQr6X; Fri Feb 18 14:39:29 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA06916 for <[e-mail]>; Fri, 18 Feb 2000 14:39:28 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <FDLFYJNY>; Fri, 18 Feb 2000 14:39:09 +1100
Message-ID: <73388857A695D31197EF00508B08F2988A3AE7@NTMSG0131>
From: "Manger, James H" <[e-mail]>
To: "'PKIX'" <[e-mail]>
Subject: RE: QC: Identification confusion continues
Date: Fri, 18 Feb 2000 14:39:03 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Charlie,

I am beginning to understand your position as more of the history of dnq is
revealed.  I can even accept your solution - imperfect but usable.  Your
solution does go against X.520's explicitly stated intention for dnq, but
perhaps "intended" does not carry the same weight as "shall" or "must" in a
standard.

If QC does revert to using dnq to disambiguate multiple John Smiths it
should add a paragraph such as:
"X.520 intended dnQualifier to disambiguate entries in different
directories, with the same value used for all entries within a directory.
This intention, which is now deprecated, does not preclude the use of
dnQualifier as defined in this standard."
This paragraph would, at last, document this interpretation of dnq in a
standard.  Future users of the standard (who will not have been privy to
these PKIX discussions, as I was not privy to other committee meetings) will
understand the clash with X.520 (and perhaps question it no more).



P.S. The "reference source" & "basis" for the objection was the 2nd sentence
of the X.520 (1993 & 1997) definition of dnQualifier.  No experience, no
implementations, no legacy systems, no commercial imperatives, no history
(well a little), no compatibility, ...

My motivation was to keep the meaning in attribute types.  I see potential
value in knowing the type of an item and in the arrangement of types
(Att/RDN/DN).  However, this value vanishes if the syntax is used without
the semantics, or at least diminished if the semantics are loosened.  This
motivation impacts dnq in two ways: firstly the much discussed clash with
the "2nd sentence" in X.520 (clash = loosened semantics), secondly the
chance to use dnq to alleviate more important semantic perversions like
VeriSign's misuse of org & org unit.  I hoped dnq could be used to include
issuer information in a subject DN without implying a strong relationship
between the subject and the info (using org implies an "affiliation" between
the two).

The end game: for a computer looking at a DN (& little else) to be able to
understand what it means.

P.S. Where is dnQualifier deprecated (standard/draft/discussion/..)?  Is it
just the "intended use" sentence that is deprecated or the whole attribute?


Received: from rafiki.ganet.org ([e-mail] [167.193.194.192]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25259 for <[e-mail]>; Thu, 17 Feb 2000 07:50:25 -0800 (PST)
Received: from LAPTOP (host51-3.birch.net [216.212.51.3]) by rafiki.ganet.org (8.8.5/8.8.5) with SMTP id KAA14516; Thu, 17 Feb 2000 10:53:41 -0500 (EST)
From: "Robert Rowland" <[e-mail]>
To: <[e-mail]>, "'SEIS-List'" <[e-mail]>
Date: Thu, 17 Feb 2000 09:52:04 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000001bf795b$81a014c0$6a6fa8c0@stefan>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

unsubscribe



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25226 for <[e-mail]>; Thu, 17 Feb 2000 07:50:01 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id QAA27286; Thu, 17 Feb 2000 16:57:03 +0100
Received: by HYDRA with Microsoft Mail id <01BF7966.5A936F20@HYDRA>; Thu, 17 Feb 2000 16:45:10 +0100
Message-ID: <01BF7966.5A936F20@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:44:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

>he WAP definition fits well in the PKIX QC definition, they just put more
>cnstraints on the usage.

The constraints are such that the existence of a serialNumber is effectively a UID
and there is no need to interpret (to create the unmistakable identity), the other subject
attributes as they are redundant.

Such certificates (with serialNumber) from a particular CA can without hesitation
be compared by a server-based RP.

That is a very clear message to someone doing an application IMO. 

Anders


/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Thursday, February 17, 2000 16:04
> To: [e-mail]; 'Stefan Santesson'; 'SEIS-List';
> '[e-mail]'
> Cc: 'Magnus Nystrom'
> Subject: RE: Serial number and dnQualifier in QC
>
>
> Stefan,
> Do you really read this list?  Overloaded semantics has been
> questioned by many others!
>
> >Neither is the concept of serial numbers defined and even if
> we all have our
> >own interpretation of what a serial number is, I se no reason, and no
> >possibility, to exactly define the concept of serialNumber
> more than the
> >current QC 03 draft already does.
>
> For a standard that is designed to support legally binding
> signatures and
> INTEROPERABILITY we have then come to the point where we
> apparently need a
> de-facto standard instead, so we know what a serialNumber really is.
> Could someone from VeriSign PLEASE inform us how YOU
> intend to utilize serialNumbers so the world has at least
> SOMETHING to cling to?
>
> Its odd that WAP-forum actually succeeded to specify
> conditions regarding serialNumber
> that absolutely does not fit within the QC-03 draft....
>
> WAP:
>
>      "Certificate-issuing applications including this
> attribute in the subject name of an entity
>      must not reuse the attribute value in certificates
> issued to other entities"
>
> That is definitely NOT applicable to a DN disambiguer
>
> And please inform ETSI that WAP-certs (that may very well be
> used in legally
> demanding situations) have another identity concept.
>
> Anders
>



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24622 for <[e-mail]>; Thu, 17 Feb 2000 07:24:58 -0800 (PST)
Received: from stefan (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA24337; Thu, 17 Feb 2000 16:28:35 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
Cc: "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:27:30 +0100
Message-ID: <000001bf795b$81a014c0$6a6fa8c0@stefan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <01BF7960.89DC22F0@HYDRA>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Anders,

The WAP definition fits well in the PKIX QC definition, they just put more
constraints on the usage.

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Thursday, February 17, 2000 16:04
> To: [e-mail]; 'Stefan Santesson'; 'SEIS-List';
> '[e-mail]'
> Cc: 'Magnus Nystrom'
> Subject: RE: Serial number and dnQualifier in QC
>
>
> Stefan,
> Do you really read this list?  Overloaded semantics has been
> questioned by many others!
>
> >Neither is the concept of serial numbers defined and even if
> we all have our
> >own interpretation of what a serial number is, I se no reason, and no
> >possibility, to exactly define the concept of serialNumber
> more than the
> >current QC 03 draft already does.
>
> For a standard that is designed to support legally binding
> signatures and
> INTEROPERABILITY we have then come to the point where we
> apparently need a
> de-facto standard instead, so we know what a serialNumber really is.
> Could someone from VeriSign PLEASE inform us how YOU
> intend to utilize serialNumbers so the world has at least
> SOMETHING to cling to?
>
> Its odd that WAP-forum actually succeeded to specify
> conditions regarding serialNumber
> that absolutely does not fit within the QC-03 draft....
>
> WAP:
>
>      "Certificate-issuing applications including this
> attribute in the subject name of an entity
>      must not reuse the attribute value in certificates
> issued to other entities"
>
> That is definitely NOT applicable to a DN disambiguer
>
> And please inform ETSI that WAP-certs (that may very well be
> used in legally
> demanding situations) have another identity concept.
>
> Anders
>



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24077 for <[e-mail]>; Thu, 17 Feb 2000 07:10:13 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id QAA23652; Thu, 17 Feb 2000 16:17:08 +0100
Received: by HYDRA with Microsoft Mail id <01BF7960.C4C4B3F0@HYDRA>; Thu, 17 Feb 2000 16:05:11 +0100
Message-ID: <01BF7960.C4C4B3F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Manger, James H'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Charles Moore'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: dnQualifier has a bright future?
Date: Thu, 17 Feb 2000 16:05:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

James,
to overload the semantics of dnQualifier is probably not requested by anybody.

But we have a "situation" where we essentially only have three more or the less
bad alternatives

1. Do as QC-03 and overload serialNumber semantics.  Has so far as I can see
   been rejected already.  Note: serialNumber is still a good UID replacement.

2  "Legalize" the current wide-spread misinterpretation of dnQualifier and deprecate 
   the "true" X520 definition based on the assumption that there is virtually no
   customer-base using it

3. Define a brand new attribute and OID for this purpose (dn disambigiuer)


Personally I think that #2 would be better as it is closer to existing misuse and probably also
have direct software support (known OID)

But, #3 is OK as well although it seems that new attributes cause a lot of worries about
broken software etc.  I am not THAT worried as QCs will require new SW that currently is not
standard anyway (like browser plugins to support signing)..

Anders




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24017 for <[e-mail]>; Thu, 17 Feb 2000 07:08:25 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id QAA23432; Thu, 17 Feb 2000 16:15:29 +0100
Received: by HYDRA with Microsoft Mail id <01BF7960.89DC22F0@HYDRA>; Thu, 17 Feb 2000 16:03:32 +0100
Message-ID: <01BF7960.89DC22F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:03:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,
Do you really read this list?  Overloaded semantics has been questioned by many others!

>Neither is the concept of serial numbers defined and even if we all have our
>own interpretation of what a serial number is, I se no reason, and no
>possibility, to exactly define the concept of serialNumber more than the
>current QC 03 draft already does.

For a standard that is designed to support legally binding signatures and
INTEROPERABILITY we have then come to the point where we apparently need a
de-facto standard instead, so we know what a serialNumber really is.
Could someone from VeriSign PLEASE inform us how YOU
intend to utilize serialNumbers so the world has at least SOMETHING to cling to?

Its odd that WAP-forum actually succeeded to specify conditions regarding serialNumber
that absolutely does not fit within the QC-03 draft....

WAP:

     "Certificate-issuing applications including this attribute in the subject name of an entity
     must not reuse the attribute value in certificates issued to other entities"

That is definitely NOT applicable to a DN disambiguer

And please inform ETSI that WAP-certs (that may very well be used in legally
demanding situations) have another identity concept.

Anders




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17925 for <[e-mail]>; Thu, 17 Feb 2000 02:51:26 -0800 (PST)
Received: from stefan (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id LAA17239 for <[e-mail]>; Thu, 17 Feb 2000 11:55:00 +0100
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Subject: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 11:53:56 +0100
Message-ID: <000c01bf7935$4a5fc080$6a6fa8c0@stefan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <01BF785F.D3A7A9B0@HYDRA>

Gentlemen,

I apologies for not being active in this debate but reading through the last
days of traffic on this subject makes me concerned.

First of all I don't like to do this debate all over again unless there are
some new circumstances that we didn't know about in the last round. And I
havn't found any so far...

We know that the dnQualifier have a defined semantics which is clearly
incompatible with a use as name collision eliminator within a DSA. Add to
this the fact that the concept of DSA is not completely relevant for subject
names in QC.

The fact above is confirmed with many persons that doesn't bother to say so
in this debate.

This leave us with serialNumber, which at this moment is being proposed to
be clarified in ITU X.520 by specifying that it can be used with any
"object" instead of just a "device".

This can be considered as a clarification more than a change, since the word
"device" isn't defined in X.509 anyway.

Neither is the concept of serial numbers defined and even if we all have our
own interpretation of what a serial number is, I se no reason, and no
possibility, to exactly define the concept of serialNumber more than the
current QC 03 draft already does.

For those who want to communicate the exact semantics of the code hold in
the serialNumber attribute, there is a solution by using the predefined
statement for attribute semantics in the qcStatemenets extension. Here you
can specify not only the semantics of the content but also the name
registration authority responsible for the code.

This solution is also proposed as a European standard, which currently is
prepared by ETSI.

It is also my understanding that the ITU editors has been informed by PKIX
through Stephen Kent that this issue is settled within PKIX.

I hope we all can move on from here and live with this.

/Stefan



Received: from hotmail.com (law-f238.hotmail.com [209.185.130.203]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA04832 for <[e-mail]>; Wed, 16 Feb 2000 07:12:04 -0800 (PST)
Received: (qmail 4582 invoked by uid 0); 16 Feb 2000 15:15:06 -0000
Message-ID: <[e-mail]>
Received: from 207.162.228.5 by www.hotmail.com with HTTP;
	Wed, 16 Feb 2000 07:15:05 PST
X-Originating-IP: [207.162.228.5]
From: "Philip Luo" <[e-mail]>
To: [e-mail]
Subject: retriveing server cert info from server
Date: Wed, 16 Feb 2000 07:15:05 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

How would I retrieve Server Cert info from a Server, I do not want to
use a browser.
I want to be able to "scan" a SSL server and view this content and
compare it to a DB.


-feng



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com



Received: from bearhub.bear.com (bearhub2.bear.com [207.162.228.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04541 for <[e-mail]>; Wed, 16 Feb 2000 07:06:03 -0800 (PST)
Received: from bear.com (localhost [127.0.0.1]) by bearhub.bear.com (8.9.3/8.9.2) with SMTP id KAA09933 for <[e-mail]>; Wed, 16 Feb 2000 10:09:33 -0500 (EST)
Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2650.10) id <192VTN2L>; Wed, 16 Feb 2000 10:12:45 -0500
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: retrieving cert info from server
Date: Wed, 16 Feb 2000 10:11:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

How would I retrieve Server Cert info from a Server,  I do not want to use a
browser. I want to be able to "scan" a SSL server and view this content and
compare it to a DB.


-feng




***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA23738 for <[e-mail]>; Wed, 16 Feb 2000 00:31:09 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA13492; Wed, 16 Feb 2000 09:37:58 +0100
Received: by HYDRA with Microsoft Mail id <01BF785F.D3A7A9B0@HYDRA>; Wed, 16 Feb 2000 09:25:55 +0100
Message-ID: <01BF785F.D3A7A9B0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Manger, James H'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: dnQualifier has a bright future?
Date: Wed, 16 Feb 2000 09:25:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Oops James,
My wording was a little bit reversed.  (-: Of course I understood that Tom meant
that the ITU-conformant definition could better be named DSAInstance.

Regarding dnQualifier I though believe it should keep both name and OID
but get a new wording that is in line with its current (incorrect) use in pretty many
places as indicated by others.  

Anders

----------
From:  Manger, James H [SMTP:[e-mail]]
Sent:  Wednesday, February 16, 2000 09:13
To:  'Anders Rundgren'
Subject:  RE: dnQualifier has a bright future?

Tom did not suggest creating DSAInstance as a replacement for DNQualifier,
he said DSAInstance might have been a better choice of name for the
DNQualifier attribute.

DNDisambiguator would be a better name than DNQualifier for qualities you
want.


> ..it was in QC for 12 months!!..
It has been in X.520 for 12 years (and QC is still a draft).



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA18768 for <[e-mail]>; Tue, 15 Feb 2000 22:35:20 -0800 (PST)
Received: from mega (t3o69p47.telia.com [62.20.145.47]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id HAA04702; Wed, 16 Feb 2000 07:42:20 +0100
Message-ID: <004701bf7850$5657e1a0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>, "Manger, James H" <[e-mail]>, <[e-mail]>
Subject: dnQualifier has a bright future?
Date: Wed, 16 Feb 2000 07:35:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA18770

Tom and James,

I guess that these recent findings should eliminate dnQualifier from the list
of subjectAttributes in son-of-RFC2459  as it apparently has nothing to
do with subject attributes.  Right?

I believe though that there is a need for a dnQualifier in the way it was interpreted
by the majority of the PKI community (it was in QC for 12 months!!!).

Tom's suggestion to create a DSAInstance replacement looks real good IMO.

Anders

-----Original Message-----
From: [e-mail] <[e-mail]>
To: Manger, James H <[e-mail]>
Cc: 'Anders Rundgren' <[e-mail]>
Date: Wednesday, February 16, 2000 01:08
Subject: RE: QC: Identification confusion continues


>     I agree that DNQualifier was defined for a completely different
>purpose, but that definition makes it much less useful as a naming
>attribute than a "tiebreaker" would be.  The name DNQualifier, along with
>the first sentence of its definition, has led many people to believe that
>it was intended to distinguish between two DN's which otherwise would have
>the same name - without further restriction on its use.  Given its actual
>definition, the name "DSAInstance" would probably be more illuminating.
>
>          Tom Gindin
>
>"Manger, James H" <[e-mail]> on 02/15/2000
>06:58:06 PM
>
>To:   "'Anders Rundgren'" <[e-mail]>
>cc:   Tom Gindin/Watson/IBM@IBMUS
>Subject:  RE: QC: Identification confusion continues
>
>
>
>X.520's definition of dnQualifier is "virtually useless" for your purposes,
>because it was defined for a completely different purpose.  The fact that
>its definition makes it "illegal to use to break ties between two users
>with
>all other attributes the same" strongly suggests it was not meant for this
>purpose.  Attempts to use it for this purpose give it new semantics.
>dnQualifier then has "multiple semantics without adding any disambiguating
>element", which is precisely your (valid) criticism of QC's use of
>serialNumber.
>




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16444 for <[e-mail]>; Tue, 15 Feb 2000 21:34:22 -0800 (PST)
Received: from mega (t1o69p43.telia.com [62.20.144.43]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id GAA03331; Wed, 16 Feb 2000 06:40:17 +0100
Message-ID: <002201bf7847$aaf02820$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Carlisle Adams" <[e-mail]>, "Stephen Kent" <[e-mail]>, "'Ed Gerck'" <[e-mail]>, <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: Re: Identification confusion continues
Date: Wed, 16 Feb 2000 06:32:58 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA16445

Carlisle,

>I try to make it a personal policy not to mention Entrust products in this
>type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
>make an exception.


thanx!

>The Entrust PKI allows the terminal RDN in a DN to be something like
>"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
>employee id.) may be used to ensure uniqueness in DNs that might otherwise
>clash (due to non-uniqueness of the common name in a large organization).
>Nothing mandated, of course; this is just a possible way of populating the
>DN field.
>
>My understanding is that a number of our customers have chosen to configure
>their DNs in this way.  This actually is current practice in many real
>environments.


I would not say that employee ids has much to do with name clashes.  Employee ids
are in 99.9% of all cases unique identities.  Name independent.  These fit the serial number description
without tweaking the original specification more than replacing device with individual.

I.e. I stay unconvinced that serialNumbers are used as dnQualifiers (which I am pretty sure
that Entrust support as well?)  in the way it was interpreted by most of the PKI community
just some months ago.

But actually this does not matter at all.  What DOES matter is that the ambigious
use of serialNumber in QC is not left in its current UNDEFINED state.

Anders



Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16216 for <[e-mail]>; Tue, 15 Feb 2000 21:27:18 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093BE4@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: QC: Identification confusion continues
Date: Wed, 16 Feb 2000 15:35:21 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

>===== Original Message From Anders Rundgren
<SMTP:[e-mail]> 
=====
>Tom,
>
>Pardon me for bringing this to the list but it is really important
>
>You may be right regarding the uselessness of dnQualifier.  My criticism of

the
>current solution is that QC assigns multiple semantics to serialNumber 
without
>adding any disambiguiting element.  That is IMO an extremely basic 
requirement.

cm> Right on....Lets see what luck you have in this forum...


>
>Actually, this debate was to a large extent initiated by my request for
>supporting
>unique identifiers as I felt that the ambiguous dnQualifier was not
>such a great idea.  And apparently that was in-line with other schemes
>like the Swedish and Finnish ID-card programs.  Now we have got
>an ambiguous serialNumber definition that at least for hands-on guys like
>me looks like no progress at all.
>
>Personally I think "esoteric" X-500 issues (taking in account that 
dnQualifier
>was
>not challenged for several years) are of limited importance for the success

of
>QC, compared to
>elementary issues like how unmistakable identities are to be interpreted by
a
>computerized
>relying party, and how unmistakable identities are to be maintained by CAs 
over
>time.
>None of this is covered by QC-03.
>
>Therefore IMO dnqualifier could without hesitation be interpreted as it
>(apparently) was
>by most people just 3 months ago.

as there are about 400Mil certs in exittance with DNq in the form you
require 
it is interesting to listen to the rastional of why they dont work...
The fact is this argument is one about a companies implementation and
exerting 
this into a standard... Might is right type argument that is more 
commercial/political rather than technical...


My one cents worth.....
An interesting side affect is that the same company is aruing in the ITU
that 
PKIX has already agreed  that serial numebvr is the ONLY solution...
Circles within circles....



And serialNumber be a replacement for the
>defunct X-500 UniqueIdentity.   Then there is a slim chance to actually
state
>some
>almost human-readable rules regarding the interpretation of identity 
information
>as well as certificate comparisons.  W.o. such rules we will continue to
>"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will 
have
>less
>to do but I can live with that...
>
>BTW, if ITU's definition of dnQualifier really is useless, is there
>no chance to make it right some day?

The ITU definitioon is ambiguios, there is no problem to solve ( see above),

the arguments are purley accademic and based on commercial interests...
Something that the ITU has traditionally been nuetral about, but this si not

the case today....

>
>Regards
>Anders
>
>----------
>From:  [e-mail] [SMTP:[e-mail]]
>Sent:  Tuesday, February 15, 2000 00:51
>To:  Anders Rundgren
>Cc:  [e-mail]
>Subject:  Re: QC: Identification confusion continues
>
>     You may remember that this subject was discussed on the PKIX list at
>considerable length during November.  James Manger pointed out that the
>definition of DNQualifier was such that it was illegal to use it to break
>ties between two users with all other attributes the same on the same DSA.
>Your misconception is partly my fault, since I sent you the suggestion to
>use DNQualifier a couple of days before James found the following clause
>("and that its value be the same in a given DSA for all entries to which
>this information has been added") in X.520's definition of DNQualifier.
>IMO, this clause makes DNQualifier virtually useless.
>     There was then a lengthy discussion of serialNumber, and the
>possibility of changing its definition in such a way as to make it useful
>for this purpose, which would at least be backward compatible.  IMHO, the
>only remaining possibilities are 1) to amend serialNumber's definition in
>X.520 and use it for QC's, and 2) to define a new attribute.  I have not,
>however, seen any such amendment of serialNumber's definition in X.520.
>     I don't think that political correctness in the usual sense of the
>term has anything to do with these decisions.  Respect for the wording of
>definitions when they have any ascertainable meaning, even when they
>reflect poor decisions, is what is driving this.
>
>          Tom Gindin


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15917 for <[e-mail]>; Tue, 15 Feb 2000 21:12:50 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093BE0@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Carlisle Adams'" <[e-mail]>
Cc: "'Ed Gerck'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Subject: RE: Identification confusion continues
Date: Wed, 16 Feb 2000 15:20:55 +1000
MIME-Version: 1.0
Content-Type: text/plain

Another data point, we allow dnq in out certifiactes exactly as Entrust do
for 
SN ( I now understand their position in the ITU on this matter)..
Anyway this is in "Root certificates that exist within MSoft and Netscape 
Browers so there are X??Million in existance today...

Just another data point...
We use DNq as it has the right semantics, we also have installations that
use 
serial number but with the right semantic...

Enjoy...



>===== Original Message From Carlisle Adams
<SMTP:[e-mail]> 
=====
>Hi,
>
>I try to make it a personal policy not to mention Entrust products in this
>type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
>make an exception.
>
>The Entrust PKI allows the terminal RDN in a DN to be something like
>"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
>employee id.) may be used to ensure uniqueness in DNs that might otherwise
>clash (due to non-uniqueness of the common name in a large organization).
>Nothing mandated, of course; this is just a possible way of populating the
>DN field.
>
>My understanding is that a number of our customers have chosen to configure
>their DNs in this way.  This actually is current practice in many real
>environments.
>
>I'd be surprised if Entrust was the only product that allowed this but, in
>any case, it's one data point.
>
>Carlisle.
>
>
>> ----------
>> From: 	Anders Rundgren[SMTP:[e-mail]]
>> Sent: 	Monday, February 14, 2000 11:09 AM
>> To: 	Stephen Kent; 'Ed Gerck'; [e-mail]; 'Stefan Santesson';
>> 'Magnus Nystrom'
>> Subject: 	RE: Identification confusion continues
>>
>> Thanx Ed!
>> It would be particularly interesting to know who actually use or intend
to
>> use serialNumber as a
>> name collision eliminator.  I.e. the function of dnQualifier according to
>> ITU...
>>
>> /anders
>>
>>
>> ----------
>> From:  Ed Gerck [SMTP:[e-mail]]
>> Sent:  Monday, February 14, 2000 16:54
>> To:  Stephen Kent
>> Cc:  Anders Rundgren; [e-mail]
>> Subject:  Re: Identification confusion continues
>>
>>
>>
>> >Stephen Kent wrote:
>>
>> >> After extensive debate, folks in the ITU and IETF worlds agreed that
>> >> the syntax of what we needed is best expressed by serialNumbner, not
>> >> DNqualifier, and that a broadening of the definition of the former
>> >> attribute was the best path.  Moreover, we had reports from various
>> >> folks that people in the field had come to the same conclusion and
>> >> were already using serialNumber in this fashion.  So, we are
>> >> legitimizing current practice, and meeting a stated need, without
>> >> introducing a new attribute type.
>>
>> >I may have missed this information in the draft?  Seems to me that it
>> >at least shows why the seemingly most obscure path was the path of
>> >choice, by calling a serialNumber what is not a "serial number".
>>
>> >BTW, could we know what "people in the field had come to the same
>> >conclusion and were already using serialNumber in this fashion" and
>> >also who were the "various folks" that reported on this?  It might be
>> >useful to get back to both sides and see exactly what is being done
>> >ahead of the standards.
>>
>> >Cheers,
>>
>> >Ed Gerck
>>


Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06504 for <[e-mail]>; Tue, 15 Feb 2000 14:41:15 -0800 (PST)
Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA24203 for <[e-mail]>; Tue, 15 Feb 2000 14:44:41 -0800 (PST)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA16690 for <[e-mail]>; Tue, 15 Feb 2000 14:44:41 -0800 (PST)
Received: from xch-pssbh-01.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 15 Feb 2000 14:44:28 -0800
Received: by xch-pssbh-01.ca.boeing.com with Internet Mail Service (5.5.2650.21) id <1MTB2JZM>; Tue, 15 Feb 2000 14:44:27 -0800
Message-Id: <[e-mail]>
From: "Pratt, Lisa M" <[e-mail]>
To: "'Luo, Feng (Exchange)'" <[e-mail]>, [e-mail]
Subject: RE: digital signature
Date: Tue, 15 Feb 2000 14:44:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I believe this site will provide you with that information.
http://www.mbc.com/ecommerce.html

Regards, Lisa
-----Original Message-----
From: Luo, Feng (Exchange) [mailto:[e-mail]]
Sent: Tuesday, February 15, 2000 2:27 PM
To: [e-mail]
Subject: digital signature


Hi,

I am looking for the information about the digital signature program of all
of states (especially NY, NJ), could some one direct me where I should go?

Thanks in advance,
feng


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************


Received: from bearhub.bear.com (bearhub2.bear.com [207.162.228.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06006 for <[e-mail]>; Tue, 15 Feb 2000 14:22:24 -0800 (PST)
Received: from bear.com (localhost [127.0.0.1]) by bearhub.bear.com (8.9.3/8.9.2) with SMTP id RAA09905 for <[e-mail]>; Tue, 15 Feb 2000 17:25:20 -0500 (EST)
Received: by whmsx2.is.bear.com with Internet Mail Service (5.5.2650.10) id <192VSRVC>; Tue, 15 Feb 2000 17:28:31 -0500
Message-ID: <[e-mail]>
From: "Luo, Feng (Exchange)" <[e-mail]>
To: [e-mail]
Subject: digital signature
Date: Tue, 15 Feb 2000 17:27:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I am looking for the information about the digital signature program of all
of states (especially NY, NJ), could some one direct me where I should go?

Thanks in advance,
feng


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05102 for <[e-mail]>; Tue, 15 Feb 2000 13:44:37 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <1TRVHYBJ>; Tue, 15 Feb 2000 16:47:32 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>
Cc: Stephen Kent <[e-mail]>, "'Ed Gerck'" <[e-mail]>, [e-mail], "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Identification confusion continues
Date: Tue, 15 Feb 2000 16:45:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi,

I try to make it a personal policy not to mention Entrust products in this
type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
make an exception.

The Entrust PKI allows the terminal RDN in a DN to be something like
"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
employee id.) may be used to ensure uniqueness in DNs that might otherwise
clash (due to non-uniqueness of the common name in a large organization).
Nothing mandated, of course; this is just a possible way of populating the
DN field.

My understanding is that a number of our customers have chosen to configure
their DNs in this way.  This actually is current practice in many real
environments.

I'd be surprised if Entrust was the only product that allowed this but, in
any case, it's one data point.

Carlisle.


> ----------
> From: 	Anders Rundgren[SMTP:[e-mail]]
> Sent: 	Monday, February 14, 2000 11:09 AM
> To: 	Stephen Kent; 'Ed Gerck'; [e-mail]; 'Stefan Santesson';
> 'Magnus Nystrom'
> Subject: 	RE: Identification confusion continues
> 
> Thanx Ed!
> It would be particularly interesting to know who actually use or intend to
> use serialNumber as a
> name collision eliminator.  I.e. the function of dnQualifier according to
> ITU...
> 
> /anders
> 
> 
> ----------
> From:  Ed Gerck [SMTP:[e-mail]]
> Sent:  Monday, February 14, 2000 16:54
> To:  Stephen Kent
> Cc:  Anders Rundgren; [e-mail]
> Subject:  Re: Identification confusion continues
> 
> 
> 
> >Stephen Kent wrote:
> 
> >> After extensive debate, folks in the ITU and IETF worlds agreed that
> >> the syntax of what we needed is best expressed by serialNumbner, not
> >> DNqualifier, and that a broadening of the definition of the former
> >> attribute was the best path.  Moreover, we had reports from various
> >> folks that people in the field had come to the same conclusion and
> >> were already using serialNumber in this fashion.  So, we are
> >> legitimizing current practice, and meeting a stated need, without
> >> introducing a new attribute type.
> 
> >I may have missed this information in the draft?  Seems to me that it
> >at least shows why the seemingly most obscure path was the path of
> >choice, by calling a serialNumber what is not a "serial number".
> 
> >BTW, could we know what "people in the field had come to the same
> >conclusion and were already using serialNumber in this fashion" and
> >also who were the "various folks" that reported on this?  It might be
> >useful to get back to both sides and see exactly what is being done
> >ahead of the standards.
> 
> >Cheers,
> 
> >Ed Gerck
> 


Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03870 for <[e-mail]>; Tue, 15 Feb 2000 13:12:19 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <1Z8X2NYW>; Tue, 15 Feb 2000 16:09:39 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E561FA5@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Processing CRLs without Issuing Distribution Points
Date: Tue, 15 Feb 2000 16:09:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

Russ:

The Annex in X.509 is written with the orientation towards how to validate a
certificate with respect to not being revoked.

That is what you want, I think.

In terms of specifics in the example below, your analysis and conclusions
are correct (as usual).

What the X.509 Annex does is define what other CRLs you may use to validate
the scope of reason code of interest to the application for give cert (A or
B) in your example.

Thus, the title of X.509 Annex is slightly misleading, but its focus is to
determine the validity of a certificate with respect to the revocation
information.  The annex does it in a modular fashion.  Any suggestions in
terms of its accuracy or presentation will be greatly appreciated by me and
the X.509 editor.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, February 15, 2000 3:59 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Processing CRLs without Issuing Distribution Points


Santosh:

We tried to mate the CRL validation section with the Certificate validation 
section.  We found that it needed to be revised for our purposes.  Also, 
the reasons was not clear (at least to Tim and I).

Consider the following example:
    Cert-A contains a CRLDP that points to CRL-X with reasons
         {keyCompromise, affiliationChanged}
    Cert-B contains a CRLDP that points to CRL-X with reasons
         {cACompromise, cessationOfOperation}
    CRL-X contains an IDP with onlySomeReasons
         {keyCompromise, cACompromise, superseded}

A certificate user that tries to validate Cert-A should consider the 
intersection of the reasons from the DRLDP and the IDP when processing 
CRL-X.  Thus, processing CRL-X only covers keyCompromise.

Similarly, a certificate user that tries to validate Cert-B, when 
processing CRL-X, get coverage for cACompromise.

Russ


At 03:24 PM 02/15/2000 -0500, Santosh Chokhani wrote:
>Russ:
>
>Do you think PKIX needs to go beyond the Annex developed for X.509, which
>now is the normative text?
>
>In other words, why can PKIX not adopt the X.509 CRL processing rules text
>or an abridged version of it?
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Tuesday, February 15, 2000 3:22 PM
>To: Sean Mullan; [e-mail]
>Cc: [e-mail]
>Subject: Re: Processing CRLs without Issuing Distribution Points
>
>
>Sean:
>
>The CRL reasons extension determines whether the CRL covers all of the
>certificates or not.  The handling of reasons turns out to be fairly
>complex.  Tim Polk and I spent quite a bit of time at a white board working
>out the details.  The CRL processing section in the soon-to-be-posted
>son-of-rfc2459 will hopefully address this.
>
>Tim:
>
>When ca we expect to see the next Internet-Draft?
>
>Russ
>
>
>At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:
>
> >RFC 2459 does not require that CRLs contain an Issuing
> >Distribution Point extension.
> >
> >Does this mean that a CA may issue *partial* CRLs without
> >including an Issuing Distribution Point Extension?
> >
> >If the answer is yes, it is not possible for a relying party to
> >safely determine if a certificate has not been revoked by inspecting
> >a CRL without an Issuing Distribution Point extension. It cannot
> >assume that a single CRL is an exhaustive list and it also cannot
> >assume a sequence of CRLs when taken as one is an exhaustive list.
> >Therefore a relying party cannot safely determine that the certificate in
> >question has not been revoked.
> >
> >RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
> >CRLs containing revoked CA certs only in the authorityRevocationList
> >attribute, but makes no mention as to whether or not those CRLs should
> >contain an Issuing Distribution Point extension. We claim they must in
> >order for a relying party to be sure that the CRL is a partial CRL
> >containing an exhaustive list of revoked CA certs only.
> >
> >Have there been any partial CRLs deployed w/o Issuing Distribution
> >Point extensions?
> >
> >We think that RFC 2459 should be changed (or made more clear) to make
> >the Issuing Distribution Point extension mandatory for CAs which split
CRLs
> >according to reason codes or user/CA type, and that relying parties
> >should treat CRLs without an Issuing Distribution Point
> >extension as complete (exhaustive) CRLs.
> >
> >--
> >Sean Mullan                     Email: [e-mail]
> >Sun Microsystems Laboratories   Tel:   [phone]
> >One Network Drive               Fax:   [phone]
> >Burlington, MA 01803-0902


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03371 for <[e-mail]>; Tue, 15 Feb 2000 13:00:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA23485; Tue, 15 Feb 2000 12:59:19 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 15 Feb 2000 15:59:09 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Processing CRLs without Issuing Distribution Points
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E561FA4@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Santosh:

We tried to mate the CRL validation section with the Certificate validation 
section.  We found that it needed to be revised for our purposes.  Also, 
the reasons was not clear (at least to Tim and I).

Consider the following example:
    Cert-A contains a CRLDP that points to CRL-X with reasons
         {keyCompromise, affiliationChanged}
    Cert-B contains a CRLDP that points to CRL-X with reasons
         {cACompromise, cessationOfOperation}
    CRL-X contains an IDP with onlySomeReasons
         {keyCompromise, cACompromise, superseded}

A certificate user that tries to validate Cert-A should consider the 
intersection of the reasons from the DRLDP and the IDP when processing 
CRL-X.  Thus, processing CRL-X only covers keyCompromise.

Similarly, a certificate user that tries to validate Cert-B, when 
processing CRL-X, get coverage for cACompromise.

Russ


At 03:24 PM 02/15/2000 -0500, Santosh Chokhani wrote:
>Russ:
>
>Do you think PKIX needs to go beyond the Annex developed for X.509, which
>now is the normative text?
>
>In other words, why can PKIX not adopt the X.509 CRL processing rules text
>or an abridged version of it?
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Tuesday, February 15, 2000 3:22 PM
>To: Sean Mullan; [e-mail]
>Cc: [e-mail]
>Subject: Re: Processing CRLs without Issuing Distribution Points
>
>
>Sean:
>
>The CRL reasons extension determines whether the CRL covers all of the
>certificates or not.  The handling of reasons turns out to be fairly
>complex.  Tim Polk and I spent quite a bit of time at a white board working
>out the details.  The CRL processing section in the soon-to-be-posted
>son-of-rfc2459 will hopefully address this.
>
>Tim:
>
>When ca we expect to see the next Internet-Draft?
>
>Russ
>
>
>At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:
>
> >RFC 2459 does not require that CRLs contain an Issuing
> >Distribution Point extension.
> >
> >Does this mean that a CA may issue *partial* CRLs without
> >including an Issuing Distribution Point Extension?
> >
> >If the answer is yes, it is not possible for a relying party to
> >safely determine if a certificate has not been revoked by inspecting
> >a CRL without an Issuing Distribution Point extension. It cannot
> >assume that a single CRL is an exhaustive list and it also cannot
> >assume a sequence of CRLs when taken as one is an exhaustive list.
> >Therefore a relying party cannot safely determine that the certificate in
> >question has not been revoked.
> >
> >RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
> >CRLs containing revoked CA certs only in the authorityRevocationList
> >attribute, but makes no mention as to whether or not those CRLs should
> >contain an Issuing Distribution Point extension. We claim they must in
> >order for a relying party to be sure that the CRL is a partial CRL
> >containing an exhaustive list of revoked CA certs only.
> >
> >Have there been any partial CRLs deployed w/o Issuing Distribution
> >Point extensions?
> >
> >We think that RFC 2459 should be changed (or made more clear) to make
> >the Issuing Distribution Point extension mandatory for CAs which split CRLs
> >according to reason codes or user/CA type, and that relying parties
> >should treat CRLs without an Issuing Distribution Point
> >extension as complete (exhaustive) CRLs.
> >
> >--
> >Sean Mullan                     Email: [e-mail]
> >Sun Microsystems Laboratories   Tel:   [phone]
> >One Network Drive               Fax:   [phone]
> >Burlington, MA 01803-0902



Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02489 for <[e-mail]>; Tue, 15 Feb 2000 12:27:21 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <1Z8X2NX3>; Tue, 15 Feb 2000 15:24:39 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E561FA4@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Sean Mullan <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Processing CRLs without Issuing Distribution Points
Date: Tue, 15 Feb 2000 15:24:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain

Russ:

Do you think PKIX needs to go beyond the Annex developed for X.509, which
now is the normative text?

In other words, why can PKIX not adopt the X.509 CRL processing rules text
or an abridged version of it?

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Tuesday, February 15, 2000 3:22 PM
To: Sean Mullan; [e-mail]
Cc: [e-mail]
Subject: Re: Processing CRLs without Issuing Distribution Points


Sean:

The CRL reasons extension determines whether the CRL covers all of the 
certificates or not.  The handling of reasons turns out to be fairly 
complex.  Tim Polk and I spent quite a bit of time at a white board working 
out the details.  The CRL processing section in the soon-to-be-posted 
son-of-rfc2459 will hopefully address this.

Tim:

When ca we expect to see the next Internet-Draft?

Russ


At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:

>RFC 2459 does not require that CRLs contain an Issuing
>Distribution Point extension.
>
>Does this mean that a CA may issue *partial* CRLs without
>including an Issuing Distribution Point Extension?
>
>If the answer is yes, it is not possible for a relying party to
>safely determine if a certificate has not been revoked by inspecting
>a CRL without an Issuing Distribution Point extension. It cannot
>assume that a single CRL is an exhaustive list and it also cannot
>assume a sequence of CRLs when taken as one is an exhaustive list.
>Therefore a relying party cannot safely determine that the certificate in
>question has not been revoked.
>
>RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
>CRLs containing revoked CA certs only in the authorityRevocationList
>attribute, but makes no mention as to whether or not those CRLs should
>contain an Issuing Distribution Point extension. We claim they must in
>order for a relying party to be sure that the CRL is a partial CRL
>containing an exhaustive list of revoked CA certs only.
>
>Have there been any partial CRLs deployed w/o Issuing Distribution
>Point extensions?
>
>We think that RFC 2459 should be changed (or made more clear) to make
>the Issuing Distribution Point extension mandatory for CAs which split CRLs
>according to reason codes or user/CA type, and that relying parties
>should treat CRLs without an Issuing Distribution Point
>extension as complete (exhaustive) CRLs.
>
>--
>Sean Mullan                     Email: [e-mail]
>Sun Microsystems Laboratories   Tel:   [phone]
>One Network Drive               Fax:   [phone]
>Burlington, MA 01803-0902


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02227 for <[e-mail]>; Tue, 15 Feb 2000 12:23:05 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA22920; Tue, 15 Feb 2000 12:21:50 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 15 Feb 2000 15:21:49 -0500
To: Sean Mullan <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Processing CRLs without Issuing Distribution Points
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sean:

The CRL reasons extension determines whether the CRL covers all of the 
certificates or not.  The handling of reasons turns out to be fairly 
complex.  Tim Polk and I spent quite a bit of time at a white board working 
out the details.  The CRL processing section in the soon-to-be-posted 
son-of-rfc2459 will hopefully address this.

Tim:

When ca we expect to see the next Internet-Draft?

Russ


At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:

>RFC 2459 does not require that CRLs contain an Issuing
>Distribution Point extension.
>
>Does this mean that a CA may issue *partial* CRLs without
>including an Issuing Distribution Point Extension?
>
>If the answer is yes, it is not possible for a relying party to
>safely determine if a certificate has not been revoked by inspecting
>a CRL without an Issuing Distribution Point extension. It cannot
>assume that a single CRL is an exhaustive list and it also cannot
>assume a sequence of CRLs when taken as one is an exhaustive list.
>Therefore a relying party cannot safely determine that the certificate in
>question has not been revoked.
>
>RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
>CRLs containing revoked CA certs only in the authorityRevocationList
>attribute, but makes no mention as to whether or not those CRLs should
>contain an Issuing Distribution Point extension. We claim they must in
>order for a relying party to be sure that the CRL is a partial CRL
>containing an exhaustive list of revoked CA certs only.
>
>Have there been any partial CRLs deployed w/o Issuing Distribution
>Point extensions?
>
>We think that RFC 2459 should be changed (or made more clear) to make
>the Issuing Distribution Point extension mandatory for CAs which split CRLs
>according to reason codes or user/CA type, and that relying parties
>should treat CRLs without an Issuing Distribution Point
>extension as complete (exhaustive) CRLs.
>
>--
>Sean Mullan                     Email: [e-mail]
>Sun Microsystems Laboratories   Tel:   [phone]
>One Network Drive               Fax:   [phone]
>Burlington, MA 01803-0902



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00942 for <[e-mail]>; Tue, 15 Feb 2000 11:33:46 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09821 for <[e-mail]>; Tue, 15 Feb 2000 11:36:46 -0800 (PST)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA17417 for <[e-mail]>; Tue, 15 Feb 2000 14:36:45 -0500 (EST)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id OAA08261; Tue, 15 Feb 2000 14:36:44 -0500 (EST)
From: Anne Anderson <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2000 14:36:44 -0500 (EST)
To: [e-mail]
Subject: excluding all distinguished names in NameConstraints
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid

If I want to create a certificate that will not allow the Subject to
issue valid certificates for non-null CertificateSubjectNames or for
SubjectAlternativeNames of type directoryName (ASN.1 "Name"), what
should be in the NameConstraintsExtension?

If I create an excluded GeneralSubtrees containing a name of type
directoryName, then the name must encompass all directoryNames, and
I don't see how that is possible.  An ASN.1 Name is a "SEQUENCE OF"
(i.e. at least 1) RelativeDistinguishedName, so I would have to
specify at least one RelativeDistinguishedName.  That means
specifying at least one AttributeType.  I have now excluded all
DistinguishedNames of that type, but have not excluded others.

If I create a permitted GeneralSubtrees containing no names of type
directoryName, then by definition all names of type directoryName
are permitted unless they are specifically excluded.  If I try to
specify a permitted directoryName GeneralSubtrees, then it must
contain at least one RDN containing at least one AttributeType, so
that directoryName type will be permitted.

The only solution I can see is to define a bogus AttributeType and
create a permitted GeneralSubtrees containing a directoryName
containing that AttributeType.

Is there a better way?  For all GeneralName types, it is possible to
create a name with the correct type but an empty value since they
are strings or SEQUENCE (not SEQUENCE OF).

Anne
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29424 for <[e-mail]>; Tue, 15 Feb 2000 10:44:41 -0800 (PST)
Received: from mega (t4o69p105.telia.com [62.20.145.225]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id TAA22775; Tue, 15 Feb 2000 19:51:42 +0100
Message-ID: <000801bf77ed$0f377370$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: QC: Unmistakable identity life-span
Date: Tue, 15 Feb 2000 19:44:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA29425

Sorry for clogging the line but here I have another QC-related issue:

I believe that there should be a requirement on a QC-conformant CA to
never reuse an unmistakable identity to another entity.  

Note that this requirement is completely independent from the unique
static identity issue.

Anders



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26006 for <[e-mail]>; Tue, 15 Feb 2000 07:53:16 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA01744; Wed, 16 Feb 2000 04:56:40 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95063020017751>; Wed, 16 Feb 2000 04:56:40 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Cert comparison needs AI?
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 16 Feb 2000 04:56:40 (NZDT)
Message-ID: <[e-mail]>

Alfred Arsenault <[e-mail]> quoted Anders Rundgren:

>(*) Lotus Notes do not accept any X509 certificates except its own according
>to a recent study by Swedish Police Authorities

Is this for v4 or v5?  Given that v5 does S/MIME (or claims to, I've never 
used it), it'd be impressive if they could do that without handling anyone 
elses certificates.

[As a side-note, given Sweden's discovery (three years after everyone else 
 knew about it :-) of Notes' differential-workfactor crypto, I'm surprised 
 they're still using it at all]

Peter.



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22637 for <[e-mail]>; Tue, 15 Feb 2000 05:39:58 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id OAA21883; Tue, 15 Feb 2000 14:42:36 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2000 14:44:05 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Marc Jadoul <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms15C184AFAE44C05F24CC7D0F"

This is a cryptographically signed message in MIME format.

--------------ms15C184AFAE44C05F24CC7D0F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marc Jadoul wrote:

> Ok, but may be there is a solution (that i never tried and it might be
> uncompatible with lot of existing software.) :
> 
> If i understand well, you do not want to have your CA keys online for
> security reason ? Or more precisely, you do not want to have some key
> online, because this key is able to sign certificates which would be
> verified by the CA certificate you published ... ?

Unfortunately the only way to be SURE the key is secure from net-attacks
is to unplug the CA... (actually...).
 
> But if you generate a second key for your CA, and use this key ONLY for
> signing CRL, you can achieve what you want.
> 
> Of course you need to sign a CA certificate for this new key. This
> certificate would be signed by your main (old) CA key, but you would use
> a keyUsage extension with only the crlSign bit set. Thus this
> certificate can not be used to verify certificates but can be used to
> verify CRLs.
> 
> It would be reasonably safe to have the second CA key online. At least
> it is as safe as what you can get with online signing of revocation
> status.
> 
> Note that you probably also need the keyid extension also to help
> software to find the good CA certificate.
> 
> Let me know if you think it is possible in real life.
> 
> Marc

I am interested in developing a CA that currently available software will
support. Many sent in the proposal to have a second key-pair on-line
for CRL signing. However, my question is: do current browsers support this
feature ??? Will them correctly import the CRLs signed and verify certificates
against it ??? Does anyone have tried so far such an approach to the problem?

C'you,

	Massimiliano Pala ([e-mail])
--------------ms15C184AFAE44C05F24CC7D0F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMjE1MTM0NDA1WjAjBgkqhkiG9w0BCQQxFgQU0fkAOIvkplIF9kyR9FEuPCnNRSgw
DQYJKoZIhvcNAQEBBQAEgYB8nbNRsjQZkU4rbQg1DtMxBacn5jCkSzPx68sVxm0UytGUhIDl
xGZeRkxHyc1sNdeNXmSzBMFD5dFMbcLIGVBPPrv0Oxm/SbJ8F8LoxY4E2IXxwgALedgCgqkE
04ZyeHVh9lnRb+BOjV5oefy130yShAl7u+aSC8efCEtOZSU8Mg==
--------------ms15C184AFAE44C05F24CC7D0F--



Received: from tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22205 for <[e-mail]>; Tue, 15 Feb 2000 05:25:48 -0800 (PST)
Received: from zanyclown.tycho.ncsc.mil (zanyclown [144.51.3.100]) by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id IAA05294; Tue, 15 Feb 2000 08:27:59 -0500 (EST)
Received: by zanyclown.tycho.ncsc.mil with Internet Mail Service (5.5.2448.0) id <D1VA7Z4W>; Tue, 15 Feb 2000 08:27:43 -0500
Message-ID: <[e-mail]>
From: Alfred Arsenault <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'J D Brooks'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Cert comparison needs AI?
Date: Tue, 15 Feb 2000 08:27:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

<Anders Rundgren wrote:>


<snip>

IMO QC-03 guarantees that the limited interoperability offered by current
PKI solutions (*) is preserved.

(*) Lotus Notes do not accept any X509 certificates except its own according
to a recent
study by Swedish Police Authorities

(*) Win2K kerberos authentication only accepts its own X509 certificates
according to
a well-known PKI evangelist in another mailing list

Anders

AWA:  It's a bit harsh to blame these things on the QC draft.  If vendors
want their applications to only accept certain certificates and to reject
certificates issued by "competitors" or "those who haven't signed the right
'partnering agreement'", there's nothing we're going to do about it in PKIX.
That's a market-driven issue, and it will always be possible for application
developers to make this so.


			Al Arsenault

-- As usual, my own opinions; may or may not resemble anything my employer
is doing; etc.



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21755 for <[e-mail]>; Tue, 15 Feb 2000 05:10:20 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id OAA30380; Tue, 15 Feb 2000 14:17:11 +0100
Received: by HYDRA with Microsoft Mail id <01BF77BD.AE20E960@HYDRA>; Tue, 15 Feb 2000 14:05:14 +0100
Message-ID: <01BF77BD.AE20E960@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'J D Brooks'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject:  RE: Cert comparison needs AI?
Date: Tue, 15 Feb 2000 14:05:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

J D,

>But isn't it the responsibility of the certificate issuing authority to
>ensure two qualified certificates never refer to the same physical entity?

It definitely should, but apparently the concept of unmistakable identity has different
meaning to different people.  As unmistakable identity is the core of Qualified Certificates
it is really sad that so little has been done to penetrate this area.

IMO QC-03 guarantees that the limited interoperability offered by current PKI solutions (*) is preserved.

(*) Lotus Notes do not accept any X509 certificates except its own according to a recent
study by Swedish Police Authorities

(*) Win2K kerberos authentication only accepts its own X509 certificates according to
a well-known PKI evangelist in another mailing list

Anders



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16770 for <[e-mail]>; Tue, 15 Feb 2000 02:27:47 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id LAA16599; Tue, 15 Feb 2000 11:34:44 +0100
Received: by HYDRA with Microsoft Mail id <01BF77A6.FE4E15F0@HYDRA>; Tue, 15 Feb 2000 11:22:50 +0100
Message-ID: <01BF77A6.FE4E15F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: QC: Identification confusion continues
Date: Tue, 15 Feb 2000 11:22:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tom,

Pardon me for bringing this to the list but it is really important

You may be right regarding the uselessness of dnQualifier.  My criticism of the
current solution is that QC assigns multiple semantics to serialNumber without
adding any disambiguiting element.  That is IMO an extremely basic requirement.

Actually, this debate was to a large extent initiated by my request for supporting
unique identifiers as I felt that the ambiguous dnQualifier was not
such a great idea.  And apparently that was in-line with other schemes
like the Swedish and Finnish ID-card programs.  Now we have got
an ambiguous serialNumber definition that at least for hands-on guys like
me looks like no progress at all.

Personally I think "esoteric" X-500 issues (taking in account that dnQualifier was
not challenged for several years) are of limited importance for the success of QC, compared to
elementary issues like how unmistakable identities are to be interpreted by a computerized
relying party, and how unmistakable identities are to be maintained by CAs over time.
None of this is covered by QC-03.

Therefore IMO dnqualifier could without hesitation be interpreted as it (apparently) was
by most people just 3 months ago.  And serialNumber be a replacement for the
defunct X-500 UniqueIdentity.   Then there is a slim chance to actually state some
almost human-readable rules regarding the interpretation of identity information
as well as certificate comparisons.  W.o. such rules we will continue to
"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will have less
to do but I can live with that...

BTW, if ITU's definition of dnQualifier really is useless, is there
no chance to make it right some day?

Regards
Anders

----------
From:  [e-mail] [SMTP:[e-mail]]
Sent:  Tuesday, February 15, 2000 00:51
To:  Anders Rundgren
Cc:  [e-mail]
Subject:  Re: QC: Identification confusion continues

     You may remember that this subject was discussed on the PKIX list at
considerable length during November.  James Manger pointed out that the
definition of DNQualifier was such that it was illegal to use it to break
ties between two users with all other attributes the same on the same DSA.
Your misconception is partly my fault, since I sent you the suggestion to
use DNQualifier a couple of days before James found the following clause
("and that its value be the same in a given DSA for all entries to which
this information has been added") in X.520's definition of DNQualifier.
IMO, this clause makes DNQualifier virtually useless.
     There was then a lengthy discussion of serialNumber, and the
possibility of changing its definition in such a way as to make it useful
for this purpose, which would at least be backward compatible.  IMHO, the
only remaining possibilities are 1) to amend serialNumber's definition in
X.520 and use it for QC's, and 2) to define a new attribute.  I have not,
however, seen any such amendment of serialNumber's definition in X.520.
     I don't think that political correctness in the usual sense of the
term has anything to do with these decisions.  Respect for the wording of
definitions when they have any ascertainable meaning, even when they
reflect poor decisions, is what is driving this.

          Tom Gindin



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA24797 for <[e-mail]>; Mon, 14 Feb 2000 15:29:27 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Feb 2000 16:32:18 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Mon, 14 Feb 2000 16:32:13 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Implementation of DN vs. SubjAltName Field
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA24798

Murray,

There has been some very interesting discussion along those lines 
on the SMIME list recently.

It has been pointed out that e-mail addresses may be an invitation to 
spamming, and that it is all too easy to forge the apparent From address
of an e-mail message if only the addr-spec portion of an RFC822 name
is matched.

In addition, as you are recognizing, it can be very difficult to get directory 
administrators to modify their directory structure, even in a fairly small 
organization. Trying to get say the US Navy to change their directory 
structure would be a mind-boggling effort.  Using the RFC822 address
as the primary key field, i.e., primary DN, would result in a very flat directory 
structure that might be hard to maintain.

A third issue is that neither ordinary directory names (as usually deployed)
nor RFC822 names are particularly meaningful or use friendly.

A fourth issue is that none of the name forms provide long term stability
across name changes, organizational changes, etc.

For long term planning, I would suggest that you consider using a constant
employeeID as the linkage between your two DIT structures, whether or not
you include this attribute in the certificate.

Then I would suggest using at least three name forms in your certificates.
the first, which I would like to see used as the primary display form for
the Signer (replacing the From address on a message banner, would be
a subjectAltName in directoryName format containing at a minimum a "real"
commonName, and not some imposed mailbox name.

The second, optional attribute displayed would be the RFC822 name, 
if present, and the third would be the DN in the certificate, which would 
match the DN in the directory.

My advice would be to not make too much of an issue about reissuing 
certificates. Certificates are going to expire in any case, and they should not 
be that expensive or hard to reissue -- if they are, you need to find a different 
CA or CA toolkit vendor, especially since it sounds like you are doing all of 
the due diligence in any case.

Regards,

Bob


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to 
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and WILL BE REPUDIATED, notwithstanding any wording or implications to the opposite effect in the text of the message itself; due in part, but not exclusively, to the fact that the security of my workstation and its associated cryptography is not judged adequately strong for such purposes at present.

>>> "Yutzy, Murray" <[e-mail]> 02/14/00 02:47PM >>>
We are attempting to accommodate a migration from a PKI that will initially
start with a dedicated PKI directory structure to a corporate directory
structure with different DIT's.  A view is to utilize the SubjAltNAme field
with the email as the unique identifier . This would then be the key field
to populate the corporate DS when that time comes. My understanding is that
if you use a DN in the Subject Field, a change in DIT would require
reissuance of the certificate.

Any pointers to additonal information to better understand how applications
utilize the Subject Field for obtaining information about the certificate
would be appreciated.

Murray Yutzy
Lockheed Martin
407/306-1917
Orlando,FL




Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24449 for <[e-mail]>; Mon, 14 Feb 2000 15:18:35 -0800 (PST)
Received: from localhost (jbrooks@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) with ESMTP id PAA10211; Mon, 14 Feb 2000 15:21:38 -0800 (PST)
Date: Mon, 14 Feb 2000 15:21:08 -0800 (PST)
From: J D Brooks <[e-mail]>
To: "David P. Kemp" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: Cert comparison needs AI?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 14 Feb 2000, David P. Kemp wrote:
<ed>
> 
> On the other hand, if two certs contain the identical unmistakeable
> identities yet refer to two different physical entities, then the
> identities must not have been so unmistakeable in the first place,
> and the QC has failed to satisfy the requirements of section 2.
> 
> Stefan, could you either delete that paragraph from "Security
> Considerations", or replace it with something like:
> 
>   "A given physical entity may have multiple forms of unmistakeable
>   identity.  It is not necessarily possible to determine by examination
>   that two qualified certificates refer to the same physical entity."
> 

But isn't it the responsibility of the certificate issuing authority to
ensure two qualified certificates never refer to the same physical entity?



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23381 for <[e-mail]>; Mon, 14 Feb 2000 14:17:39 -0800 (PST)
Received: from mega (t4o69p53.telia.com [62.20.145.173]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id XAA07924; Mon, 14 Feb 2000 23:24:01 +0100
Message-ID: <003001bf7741$8d8de710$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Re: SEIS:  RE: Cert comparison needs AI?
Date: Mon, 14 Feb 2000 23:16:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA23382

David,

>"ensuring uniqueness" is a defined semantic, even if the process by
>which uniqueness is ensured is relegated to the CPS (or CP) for a
>particular domain.  Although I have one quarrel with the definition, I
>basically agree with Stefan that using the serialNumber attribute to
>contain a true serial number (a static identifier which refers to the
>same entity even when the Common Name changes) fits within an amended
>definition:


I have never said it does not fit the definition, I just dislike the idea to overload the semantics
of serialNumber with the semantics of dnQualifier and not having any defined way in the certificate
to specify which semantic the certificate is actually using.

>  "Comparing two qualified certificates to determine if they
>  represent the same physical entity may provide misleading results
>  and should be performed with care."
>
>It is obvious that just because a QC contains an "unmistakeable
>identity" does not imply that there is only one possible unmistaken
>identity for a given physical entity. It's hard to see how this
>result would be "misleading" to anyone.
>
>On the other hand, if two certs contain the identical unmistakeable
>identities yet refer to two different physical entities, then the
>identities must not have been so unmistakeable in the first place,
>and the QC has failed to satisfy the requirements of section 2.


I would say that the QC sample is an example of a certificate that
could generate incorrect results as it seems that a QC-conforming
CA could issue certificates for a person with a certain name and later
(maybe after the person is dead or removed from the files)
issue a certificate for a person with identical name, etc.

CONCLUSION: If QCs can be compared or not is an IMPORTANT (as it is
performed right now in many pre-QC systems using unique identifiers)
QC property that either is a part of the CPS or (even better), becomes
a property of the QC itself.

Anders



Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22816 for <[e-mail]>; Mon, 14 Feb 2000 13:54:26 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id QAA23880 for <[e-mail]>; Mon, 14 Feb 2000 16:57:48 -0500 (EST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <[e-mail]> for [e-mail]; Mon, 14 Feb 2000 16:55:55 -0500 (EST)
Received: from emss03i01.ems.lmco.com ([141.240.30.127]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <[e-mail]> for [e-mail]; Mon, 14 Feb 2000 16:50:22 -0500 (EST)
Received: by emss03i01.orl.lmco.com with Internet Mail Service (5.5.2650.21)	id <1X7WA34X>; Mon, 14 Feb 2000 16:50:12 -0500
Content-return: allowed
Date: Mon, 14 Feb 2000 16:47:16 -0500
From: "Yutzy, Murray" <[e-mail]>
Subject: Implementation of DN vs. SubjAltName Field
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

We are attempting to accommodate a migration from a PKI that will initially
start with a dedicated PKI directory structure to a corporate directory
structure with different DIT's.  A view is to utilize the SubjAltNAme field
with the email as the unique identifier . This would then be the key field
to populate the corporate DS when that time comes. My understanding is that
if you use a DN in the Subject Field, a change in DIT would require
reissuance of the certificate.

Any pointers to additonal information to better understand how applications
utilize the Subject Field for obtaining information about the certificate
would be appreciated.

Murray Yutzy
Lockheed Martin
407/306-1917
Orlando,FL



Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22141 for <[e-mail]>; Mon, 14 Feb 2000 13:19:37 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22726; Mon, 14 Feb 2000 14:22:57 -0700 (MST)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA18961; Mon, 14 Feb 2000 16:22:55 -0500 (EST)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id QAA06839; Mon, 14 Feb 2000 16:22:54 -0500 (EST)
From: Anne Anderson <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2000 16:22:54 -0500 (EST)
To: "David P. Kemp" <[e-mail]>, "Peter Gutmann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Recommended change to Unique Identifier handling
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid

Peter Gutman writes:
 > Given that no major[0] CA has ever used UID's, is this really an issue?  I 
 > assume (based on the above message) that someone somewhere is currently using 
 > them despite their having been deprecated for some time, but is it the job of 
 > PKIX to accomodate out-of-spec implementations?

In that case, why not just say: if certificate contains a SubjectUID
or IssuerUID, reject the certificate.  I'm assuming there was some
reason for addressing handling of UIDs in PKIX Part 1, and I am
trying to make such handling consistent and interoperable between
compliant and non-compliant CAs.

David P. Kemp writes:
 > In your example, CA2 has a SubjectUID=null, but it issues a cert to EE1
 > with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such
 > an unorthodox cert?

CA2 may not even know that CA1 has issued a certificate for it (it
may be a cross-certificate).  CA2 may have a self-cert that does
have a SubjectUID in it, and it used that as a base when issuing the
certificate for EE1:

  Trust Anchor 2: Issuer:  CA2
                  Subject: CA2
                  IssuerUID:  CA2-UID
                  SubjectUID: CA2-UID


 > Comments interspersed below ...
 > > b) Assuming a CA is willing to stray from the recommendation in the
 > >    interests of interoperability, then each time the CA signs a CA
 > >    certificate, it MUST know the Issuer Unique Identifier value that
 > >    the subject will store in certificates it generates, and must set
 > >    that value in the certificate's Subject Unique Identifier field.
 > >    Yet the subject may become PKIX-compliant and cease issuing
 > >    certificates with Issuer Unique Identifier values at any time.
 > 
 > In your example of CA1=anchor, CA2, and EE1:  when CA1 signs a
 > certificate for CA2, CA1 MUST know the Issuer UID that CA2 will store
 > in certificates it generates.  That's one way of looking at it, but
 > it seems to reverse cause and effect.  I would look at the situation
 > as:
 > 
 >  1) CA1 issues a cert to CA2 containing a null or non-null SubjectUID.
 >  2) CA2 uses its own SubjectUID as the IssuerUID in all EE certs it issues.
 > 
 > If CA2 wants to become PKIX-compliant and stop issuing UID certs, it
 > can request two certs from CA1 - one with SubjectUID populated to use
 > before the transition, and one with SubjectUID null to use afterwards.
 > Might as well rollover CA2's keypair at the same time, just to make it
 > obvious which EE certs belong in which path.

This would work, although it requires CA2 to know that CA1 is
issuing certificates for it, and it requires CA1 to keep track of
the extra certificate.

 > > c) Again, in the interests of interoperability, each time a CA signs
 > >    a certificate, it MUST know the Subject Unique Identifier stored
 > >    in any certificates that other CAs have signed for itself, and
 > >    MUST use that Subject Unique Identifier as the Issuer Unique
 > >    Identifier in ALL certificates it signs. Since Subject Unique
 > >    Identifier values are completely arbitrary, they may vary across
 > >    different CAs that create certificates for the same principal.
 > >    This creates an impossible situation.
 > 
 > If CA1, CAx, and CAy all issue certs to CA2 with different SubjectUIDs
 > (or different public keys or different Subject names), you have an
 > impossible situation.  UID is not unique in this respect - the issuers
 > simply can't be completely arbitrary in what they say about CA2 and
 > still expect paths to CA2's preexisting EEs to validate.

Point taken.

 > I don't think any change to PKIX UID processing rules is necessary.
 > Assuming that there are currently any CAs which use UIDs, if the CAs
 > can't manage themselves to transition from UID-full to UID-less
 > operation, how could we possibly expect a much more diverse set of
 > client applications to implement your recommended changes?

Because my recommended changes are simple, logical, require no
additional certificates, and make no assumptions about how much the
subject of a certificate knows about the issuers.

In any case, the section 6.1.4 needs to be augmented to explain how
the value of working_issuer_UID is updated in preparation for the
next certificate (e.g. set it to certificate Subject UID).

Anne
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21272 for <[e-mail]>; Mon, 14 Feb 2000 12:43:38 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA02459 for <[e-mail]>; Mon, 14 Feb 2000 15:47:25 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA02452 for <[e-mail]>; Mon, 14 Feb 2000 15:47:25 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA16438 for <[e-mail]>; Mon, 14 Feb 2000 15:47:18 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA13845 for <[e-mail]>; Mon, 14 Feb 2000 15:44:34 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 14 Feb 2000 15:44:34 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Recommended change to Unique Identifier handling
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FEmlgx6orA8gFHIdwxrtyw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Anne,

Ignoring for a moment Peter's question as to whether any Internet-domain
CAs actually populate UID, I am still curious how an interoperability
problem could arise.

In your example, CA2 has a SubjectUID=null, but it issues a cert to EE1
with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such
an unorthodox cert?

Comments interspersed below ...


> From: Anne Anderson <[e-mail]>
> 
> There are problems with the processing of Unique Identifier values
> as currently specified in draft-ietf-pkix-new-part1-00.txt,
> including the following:
> 
> a) PKIX recommends that PKIX-compliant CAs should not set Subject
>    and Issuer UID values.  This makes it impossible for certificates
>    from non-compliant CAs that use UIDs to be used as links in a
>    chain that includes certificates from compliant CAs.  This
>    creates a serious interoperability problem during the period
>    before all CAs become fully PKIX-compliant.
> 
> b) Assuming a CA is willing to stray from the recommendation in the
>    interests of interoperability, then each time the CA signs a CA
>    certificate, it MUST know the Issuer Unique Identifier value that
>    the subject will store in certificates it generates, and must set
>    that value in the certificate's Subject Unique Identifier field.
>    Yet the subject may become PKIX-compliant and cease issuing
>    certificates with Issuer Unique Identifier values at any time.

In your example of CA1=anchor, CA2, and EE1:  when CA1 signs a
certificate for CA2, CA1 MUST know the Issuer UID that CA2 will store
in certificates it generates.  That's one way of looking at it, but
it seems to reverse cause and effect.  I would look at the situation
as:

 1) CA1 issues a cert to CA2 containing a null or non-null SubjectUID.
 2) CA2 uses its own SubjectUID as the IssuerUID in all EE certs it issues.

If CA2 wants to become PKIX-compliant and stop issuing UID certs, it
can request two certs from CA1 - one with SubjectUID populated to use
before the transition, and one with SubjectUID null to use afterwards.
Might as well rollover CA2's keypair at the same time, just to make it
obvious which EE certs belong in which path.

> c) Again, in the interests of interoperability, each time a CA signs
>    a certificate, it MUST know the Subject Unique Identifier stored
>    in any certificates that other CAs have signed for itself, and
>    MUST use that Subject Unique Identifier as the Issuer Unique
>    Identifier in ALL certificates it signs. Since Subject Unique
>    Identifier values are completely arbitrary, they may vary across
>    different CAs that create certificates for the same principal.
>    This creates an impossible situation.

If CA1, CAx, and CAy all issue certs to CA2 with different SubjectUIDs
(or different public keys or different Subject names), you have an
impossible situation.  UID is not unique in this respect - the issuers
simply can't be completely arbitrary in what they say about CA2 and
still expect paths to CA2's preexisting EEs to validate.

I don't think any change to PKIX UID processing rules is necessary.
Assuming that there are currently any CAs which use UIDs, if the CAs
can't manage themselves to transition from UID-full to UID-less
operation, how could we possibly expect a much more diverse set of
client applications to implement your recommended changes?

Dave Kemp



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16838 for <[e-mail]>; Mon, 14 Feb 2000 10:54:09 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA13695 for <[e-mail]>; Tue, 15 Feb 2000 07:57:27 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95055464701600>; Tue, 15 Feb 2000 07:57:27 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Recommended change to Unique Identifier handling
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 15 Feb 2000 07:57:27 (NZDT)
Message-ID: <[e-mail]>

Anne Anderson <[e-mail]> writes:

>There are problems with the processing of Unique Identifier values as
>currently specified in draft-ietf-pkix-new-part1-00.txt, including the
>following:
>
>a) PKIX recommends that PKIX-compliant CAs should not set Subject
>   and Issuer UID values.  This makes it impossible for certificates
>   from non-compliant CAs that use UIDs to be used as links in a
>   chain that includes certificates from compliant CAs.  This
>   creates a serious interoperability problem during the period
>   before all CAs become fully PKIX-compliant.

Given that no major[0] CA has ever used UID's, is this really an issue?  I 
assume (based on the above message) that someone somewhere is currently using 
them despite their having been deprecated for some time, but is it the job of 
PKIX to accomodate out-of-spec implementations?

Peter.

[0] "major" = visible enough that interoperability with others will be a 
    problem.




Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16399 for <[e-mail]>; Mon, 14 Feb 2000 10:48:08 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA05887; Mon, 14 Feb 2000 13:51:52 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA05878; Mon, 14 Feb 2000 13:51:51 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA13902; Mon, 14 Feb 2000 13:51:44 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA13822; Mon, 14 Feb 2000 13:49:01 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 14 Feb 2000 13:49:01 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Cert comparison needs AI?
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: k9bXtm+kShyFyba8zm6PMw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Paul Koning <[e-mail]>
> 
> >>>>> "Anders" == Anders Rundgren <[e-mail]> writes:
> 
>  Anders> Stefan,
>  >> It means that when you form an application, you have to handle
>  >> this with care and make sure that the application don't produce
>  >> missleading results.
> 
>  Anders> Noop. In the absence of defined semantics, this property or
>  Anders> quality MUST be a part of a valid QC CPS.  The German (QC
>  Anders> sample?) CPS must state that you can't compare German QCs (or
>  Anders> do it on your own risk) while the Swedish and Finnish ID-card
>  Anders> programs guarantee that you can trust the static unique ID as
>  Anders> being the sole attribute to compare (after you have detected
>  Anders> that the cert really is belonging to these domains).
> 
> Maybe I'm reading too much into this.  Or my expectations are too
> high.  But it surely strikes me as very odd to have a "data type"
> whose semantics -- if any -- depend on the value of some unrelated
> other data object.  I suppose you could argue that it's like a tagged
> union type, but that seems a bit of a stretch.
> 
> To put it differently, on what principles is a person supposed to
> judge the merits of a proposed standard that contains components whose 
> meanings, if any, are undefined?



"Undefined" is overstating the case.  QC-03 says:

   "The serialNumber attribute type SHALL, when present, be used
   to differentiate between names where the subject field would
   otherwise be identical.  This attribute has no defined semantics
   beyond ensuring uniqueness of subject names."

"ensuring uniqueness" is a defined semantic, even if the process by
which uniqueness is ensured is relegated to the CPS (or CP) for a
particular domain.  Although I have one quarrel with the definition, I
basically agree with Stefan that using the serialNumber attribute to
contain a true serial number (a static identifier which refers to the
same entity even when the Common Name changes) fits within an amended
definition:

Stefan, could you change "would otherwise be identical" to
"might otherwise be identical" in the definition of serialNumber?
The former implies that serialNumber SHALL be used only in the case
of a known collision, whereas the latter accommodates the prophylactic
use of serialNumber in all certificates (within a given domain) to
eliminate the potential for collision.



I agree with Anders that the penultimate paragraph under "Security
Considerations" is not particularly helpful as it stands:

  "Comparing two qualified certificates to determine if they
  represent the same physical entity may provide misleading results
  and should be performed with care."

It is obvious that just because a QC contains an "unmistakeable
identity" does not imply that there is only one possible unmistaken
identity for a given physical entity. It's hard to see how this
result would be "misleading" to anyone.

On the other hand, if two certs contain the identical unmistakeable
identities yet refer to two different physical entities, then the
identities must not have been so unmistakeable in the first place,
and the QC has failed to satisfy the requirements of section 2.

Stefan, could you either delete that paragraph from "Security
Considerations", or replace it with something like:

  "A given physical entity may have multiple forms of unmistakeable
  identity.  It is not necessarily possible to determine by examination
  that two qualified certificates refer to the same physical entity."



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16185 for <[e-mail]>; Mon, 14 Feb 2000 10:46:33 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id TAA00646; Mon, 14 Feb 2000 19:53:20 +0100
Received: by HYDRA with Microsoft Mail id <01BF7723.7AF46160@HYDRA>; Mon, 14 Feb 2000 19:41:26 +0100
Message-ID: <01BF7723.7AF46160@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Paul Koning'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: QC: Indentication confusion continues
Date: Mon, 14 Feb 2000 19:41:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Oops,
You are right.  Swedish and Finnish citizen registration numbers are (supposed to be) unique though.
Within their respectively naming domain only of course.

Anders

----------
From:  Paul Koning [SMTP:[e-mail]]
Sent:  Monday, February 14, 2000 17:37
To:  [e-mail]
Cc:  [e-mail]; [e-mail]; [e-mail]
Subject:  Re: QC: Indentication confusion continues

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> ...  I.e. that SSN's and similar unique identities ...

SSNs aren't unique identities.

	paul



Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15473 for <[e-mail]>; Mon, 14 Feb 2000 10:35:34 -0800 (PST)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by crack.x509.com (8.9.3/XCERT) with ESMTP id KAA15324 for <[e-mail]>; Mon, 14 Feb 2000 10:38:56 -0800 (PST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2000 10:40:18 -0800
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Request for Opinion - LDAP Proxy in a PKI environment
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed Greshko wrote:
> 
> Hello,
> 
> A question has begun to crop up in various places about the suitability of
> using an LDAP proxy with caching in a PKI environment.  The particular
> environment in question uses CRLs stored in a single LDAP object.
> 
> My initial reaction to this is that it would be undesirable to deploy a
> proxy with caching.
> 
> I'm interested in what views others would have.....
> 
> Thanks,
> Ed

You are essentially correct, Ed.

The caching proxy basically becomes a trusted entity, because you're trusting
it to notice that the CRL has been updated in the CA's directory server. 
Because a user has no way of knowing whether or not a CRL has been issued
before the previous CRL's nextUpdate time, the user has to trust the proxy to
fetch new CRLs.

This makes the proxy a target for attacks, because if I can get your proxy to
serve stale-but-unexpired CRLs I can get you to accept a recently-revoked
certificate.

This applies to all kinds of caching proxies, not just LDAP ones.  OCSP
suffers the same problem when caching HTTP proxies are used.  In a PKI, you
have to trust your direct source of information, be it a proxy, a directory,
or a CA's own server.

The implications of this for using untrusted directories in a PKI is left as
an exercise for the reader.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12326 for <[e-mail]>; Mon, 14 Feb 2000 09:17:57 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQicjt22906; Mon, 14 Feb 2000 17:21:00 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18226; Mon, 14 Feb 00 12:18:14 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA26881; Mon, 14 Feb 2000 12:20:59 -0500
Date: Mon, 14 Feb 2000 12:20:59 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Cert comparison needs AI?
References: <01BF76C6.FD06B2A0@HYDRA>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> Stefan,
 >> It means that when you form an application, you have to handle
 >> this with care and make sure that the application don't produce
 >> missleading results.

 Anders> Noop. In the absence of defined semantics, this property or
 Anders> quality MUST be a part of a valid QC CPS.  The German (QC
 Anders> sample?) CPS must state that you can't compare German QCs (or
 Anders> do it on your own risk) while the Swedish and Finnish ID-card
 Anders> programs guarantee that you can trust the static unique ID as
 Anders> being the sole attribute to compare (after you have detected
 Anders> that the cert really is belonging to these domains).

Maybe I'm reading too much into this.  Or my expectations are too
high.  But it surely strikes me as very odd to have a "data type"
whose semantics -- if any -- depend on the value of some unrelated
other data object.  I suppose you could argue that it's like a tagged
union type, but that seems a bit of a stretch.

To put it differently, on what principles is a person supposed to
judge the merits of a proposed standard that contains components whose 
meanings, if any, are undefined?

	paul



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10942 for <[e-mail]>; Mon, 14 Feb 2000 08:47:56 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02069 for <[e-mail]>; Mon, 14 Feb 2000 08:51:16 -0800 (PST)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA03235; Mon, 14 Feb 2000 11:51:13 -0500 (EST)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id LAA06594; Mon, 14 Feb 2000 11:51:13 -0500 (EST)
Date: Mon, 14 Feb 2000 11:51:13 -0500 (EST)
Message-Id: <[e-mail]>
From: Anne Anderson <[e-mail]>
To: [e-mail]
Subject: Recommended change to Unique Identifier handling

There are problems with the processing of Unique Identifier values
as currently specified in draft-ietf-pkix-new-part1-00.txt,
including the following:

a) PKIX recommends that PKIX-compliant CAs should not set Subject
   and Issuer UID values.  This makes it impossible for certificates
   from non-compliant CAs that use UIDs to be used as links in a
   chain that includes certificates from compliant CAs.  This
   creates a serious interoperability problem during the period
   before all CAs become fully PKIX-compliant.

b) Assuming a CA is willing to stray from the recommendation in the
   interests of interoperability, then each time the CA signs a CA
   certificate, it MUST know the Issuer Unique Identifier value that
   the subject will store in certificates it generates, and must set
   that value in the certificate's Subject Unique Identifier field.
   Yet the subject may become PKIX-compliant and cease issuing
   certificates with Issuer Unique Identifier values at any time.

c) Again, in the interests of interoperability, each time a CA signs
   a certificate, it MUST know the Subject Unique Identifier stored
   in any certificates that other CAs have signed for itself, and
   MUST use that Subject Unique Identifier as the Issuer Unique
   Identifier in ALL certificates it signs.  Since Subject Unique
   Identifier values are completely arbitrary, they may vary across
   different CAs that create certificates for the same principal.
   This creates an impossible situation.

EXAMPLE
=======

To illustrate these problems, consider the following path example,
and assume that everything except the IssuerUID verifies:

Trust anchor: Issuer:  CA1
              Subject: CA1
              IssuerUID: null
              SubjectUID: null

2nd cert:     Issuer:  CA1
              Subject: CA2
              IssuerUID: null
              SubjectUID: null

3rd cert:     Issuer:  CA2
              Subject: EE1
              IssuerUID: CA2-UID
              SubjectUID: null

According to the current draft-ietf-pkix-new-part1-00.txt, this
certification path should be rejected at the 3rd certificate since
the Issuer Unique Identifier in the 3rd certificate does not match
the "working_issuer_UID", which is null.

RECOMMENDED CHANGES
===================

To address these problems, I recommend that Unique Identifier
matching be used as part of path processing only if the preceding
certificate has a non-null Subject Unique Identifier and the current
certificate has a non-null Issuer Unique Identifier.

In other words, absence of a Subject Unique Identifier field in a
certificate logically means the issuer does not care what Issuer
Unique Identifier value (if any) is used in subsequent certificates.

And, absence of an Issuer Unique Identifier value in a certificate
logically means the issuer does not care (or know) what Subject
Unique Identifier was used in certificates that might preceed this
one in a certification path.

Recommended changes to the text of draft-ietf-pkix-new-part1-00.txt:

[Change 6.1.3 (5) to:]
   6.1.3 Basic Certificate Processing
   ....
         (5) If the certificate issuer unique identifier field is
             present and non-null, and if the working_issuer_UID is
             non-null, then the value of the certificate issuer unique
             identifier must match the value of the working_issuer_UID.

[Add 6.1.5 (h):]
   6.1.5 Wrap-up procedure

   To complete the processing of the end entity certificate, perform the
   following steps for certificate n:
   ....
      (h) If the certificate subject unique identifier field is
          present and non-null, set the value of working_issuer_UID
          to the value of the certificate subject unique identifier
          field.  Otherwise, set the value of working_issuer_UID to
          null.

Anne
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09998 for <[e-mail]>; Mon, 14 Feb 2000 08:33:48 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQicjq01146; Mon, 14 Feb 2000 16:36:40 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA17325; Mon, 14 Feb 00 11:33:50 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA26854; Mon, 14 Feb 2000 11:36:35 -0500
Date: Mon, 14 Feb 2000 11:36:35 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: QC: Indentication confusion continues
References: <001a01bf75f8$f816db90$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Anders" == Anders Rundgren <[e-mail]> writes:

 Anders> ...  I.e. that SSN's and similar unique identities ...

SSNs aren't unique identities.

	paul


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08846 for <[e-mail]>; Mon, 14 Feb 2000 08:14:16 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id RAA26067; Mon, 14 Feb 2000 17:21:06 +0100
Received: by HYDRA with Microsoft Mail id <01BF770E.384E3440@HYDRA>; Mon, 14 Feb 2000 17:09:14 +0100
Message-ID: <01BF770E.384E3440@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Ed Gerck'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: Identification confusion continues
Date: Mon, 14 Feb 2000 17:09:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanx Ed!
It would be particularly interesting to know who actually use or intend to use serialNumber as a
name collision eliminator.  I.e. the function of dnQualifier according to ITU...

/anders


----------
From:  Ed Gerck [SMTP:[e-mail]]
Sent:  Monday, February 14, 2000 16:54
To:  Stephen Kent
Cc:  Anders Rundgren; [e-mail]
Subject:  Re: Identification confusion continues



>Stephen Kent wrote:

>> After extensive debate, folks in the ITU and IETF worlds agreed that
>> the syntax of what we needed is best expressed by serialNumbner, not
>> DNqualifier, and that a broadening of the definition of the former
>> attribute was the best path.  Moreover, we had reports from various
>> folks that people in the field had come to the same conclusion and
>> were already using serialNumber in this fashion.  So, we are
>> legitimizing current practice, and meeting a stated need, without
>> introducing a new attribute type.

>I may have missed this information in the draft?  Seems to me that it
>at least shows why the seemingly most obscure path was the path of
>choice, by calling a serialNumber what is not a "serial number".

>BTW, could we know what "people in the field had come to the same
>conclusion and were already using serialNumber in this fashion" and
>also who were the "various folks" that reported on this?  It might be
>useful to get back to both sides and see exactly what is being done
>ahead of the standards.

>Cheers,

>Ed Gerck



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07767 for <[e-mail]>; Mon, 14 Feb 2000 07:51:35 -0800 (PST)
Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 12KNpr-0002Sk-00; Mon, 14 Feb 2000 15:54:51 +0000
Received: from [209.21.28.71] (helo=nma.com) by dfw-mmp3.email.verio.net with esmtp (Exim 3.12 #7) id 12KNp2-0007hs-00; Mon, 14 Feb 2000 15:54:01 +0000
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2000 07:53:59 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Identification confusion continues
References: <01BF76C3.50D463E0@HYDRA> <v04220802b4cdcfa979ba@[171.78.30.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> After extensive debate, folks in the ITU and IETF worlds agreed that
> the syntax of what we needed is best expressed by serialNumbner, not
> DNqualifier, and that a broadening of the definition of the former
> attribute was the best path.  Moreover, we had reports from various
> folks that people in the field had come to the same conclusion and
> were already using serialNumber in this fashion.  So, we are
> legitimizing current practice, and meeting a stated need, without
> introducing a new attribute type.

I may have missed this information in the draft?  Seems to me that it
at least shows why the seemingly most obscure path was the path of
choice, by calling a serialNumber what is not a "serial number".

BTW, could we know what "people in the field had come to the same
conclusion and were already using serialNumber in this fashion" and
also who were the "various folks" that reported on this?  It might be
useful to get back to both sides and see exactly what is being done
ahead of the standards.

Cheers,

Ed Gerck




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06943 for <[e-mail]>; Mon, 14 Feb 2000 07:36:39 -0800 (PST)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA18667; Mon, 14 Feb 2000 10:39:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b4cdcfa979ba@[171.78.30.107]>
In-Reply-To: <01BF76C3.50D463E0@HYDRA>
References: <01BF76C3.50D463E0@HYDRA>
Date: Mon, 14 Feb 2000 10:31:42 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Identification confusion continues
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:13 AM +0100 2/14/00, Anders Rundgren wrote:
>Stefan,
>
>  >Your way of using serialNumber fits well in the QC definition. We could not
>  >limit the use of serialNumber to a static identifier based on the past
>  >discussions.
>
>And your way of assigning multiple semantics to an object without having
>any disambiguiting element is a practice that usually renders you a 
>kick in the rear in most places of this industry.
>To put such constructs in an international standard-to-be is 
>definitely a step up on the penalty ladder.
>
>/Anders


After extensive debate, folks in the ITU and IETF worlds agreed that 
the syntax of what we needed is best expressed by serialNumbner, not 
DNqualifier, and that a broadening of the definition of the former 
attribute was the best path.  Moreover, we had reports from various 
folks that people in the field had come to the same conclusion and 
were already using serialNumber in this fashion.  So, we are 
legitimizing current practice, and meeting a stated need, without 
introducing a new attribute type.

Steve



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04489 for <[e-mail]>; Mon, 14 Feb 2000 05:35:38 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17412 for <[e-mail]>; Mon, 14 Feb 2000 14:38:57 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Feb 2000 14:38:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Keeping the flames from Mr Manuel Heras-Gilsanz out of the debate,
let us see how we can modify the draft for "the benefit of
interoperability with alien civilisations !! ".    :-)

My role, as the lead editor, is to try to obtain a working group
consensus. Thanks to Tom Gindin for his proposal leading the way to
a consensus.

We need to solve three issues if we want to guarantee a smooth
co-existence of the two standards.

1. the form of the request,
2. the error codes attached with the response,
3. the form of the response.

1. The form of the request

Tom's proposal, agreed by Roland, is for ISO to add an optional
mechanism parameter that will be defaulted to the IETF mechanism,
i.e. digital signature.

This allows the same server to listen to the same port and respond
to IETF conformant requests or ISO conformant requests, provided
that ISO adopts the same parameters of the request that the IETF
defines.

In practice we will have the ISO protocol as a superset from the
IETF protocol. If someone wants to speak of one protocol but not the
other how should we name it ? Since everything is very simple with
our WG (think about SCVP), why don't we rename it: "Simple Time
Stamping Protocol (STSP)" ?

ISO could then call their version something like "eXtended Time
Stamping Protocol (XTSP)"or, whatever they like, provided that the
name is different.

2. The error code attached with the request or the response

It is anticipated that ISO will need a few error codes that are not
all yet defined. These error codes must not collide. The best way I
see to deal with this issue is that we reserve some error codes in
our specification and let them know that they are exclusively to be
allocated by ISO SC 27. We do not even need to say in the
specification that they are for ISO. The IETF WG (and chairs) will
remember not to use them for IETF purposes. However we need to know
how many they anticipate. Five, ten ?

3. The form of the response

The response may be quite different, so there is no need for
alignment. However, it will be certainly useful to be able to
reference the two data structures from the response so that they can
be used in other data structures. We have done this for our data
structure in the annex A where we define a Signature Timestamp
attribute using the following object identifier:

id-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa (2)
id-aa-timeStampToken (14)}

ISO might wish to define another OID for their data structure which
will have to bear a name different from "SignatureTimeStampToken ".
I would suggest that they use someting like
"SignatureExtendedTimeStampToken" or anything else they wish,
provided that it is different.

Other matters: Response to Tom's questions

I answered to Tom's first question (should the mechanismNotSupported
bit be added to PKIFailureInfo in the PKIX draft?) by proposing to
reserve a few error codes (to ISO).

The second question raised by Tom, was: "Should the ISO ASN.1 format
for TimeStampReq and TSTInfo be documented in an appendix to the
PKIX draft, pointing out that these are fully compatible with the
PKIX definitions within the existing draft?

The answer to that question is fairly simple. No, because we can't !
We do not know yet what they will be, be since the ISO process is
still long and no one can predict what will be the final result. We
cannot wait until the completion of the ISO work to publish our
standard.

Conclusion

Besides the other minor fixes around the ASN1 syntax, I believe that
we are now close to a consensus. I would like to hear about the WG
to see if this opinion is shared and then I will post to the mailing
list the changes that I propose as a result of the last call.

Please, leave flames out of the debate.  :-)

Regards,

Denis


Received: from www.initech.com ([203.238.37.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02876 for <[e-mail]>; Mon, 14 Feb 2000 03:34:07 -0800 (PST)
Received: from sigma ([203.238.37.133]) by www.initech.com (8.8.8H1/8.8.8) with ESMTP id UAA10617 for <[e-mail]>; Mon, 14 Feb 2000 20:32:22 +0900 (KST)
From: "Kwon, YongChul" <[e-mail]>
To: <[e-mail]>
Subject: salt in Password Based MAC
Date: Mon, 14 Feb 2000 20:32:23 +0900
Message-ID: <001401bf76df$2a334190$8525eecb@sigma>
MIME-Version: 1.0
Content-Type: text/plain; charset="euc-kr"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id DAA02878

How should I make the first input value of first iteration of PBM?

salt||sharedsecret or sharedsecret||salt? ('||' means concatenation)

I think RFC-2510 said message||salt, but I can't sure. :-(

I attach part of RFC-2510 which refers how to make initial input.

-----

3.1.3 PKI Message Protection

...

In the above protectionAlg the salt value is appended to the shared
secret input. The OWF is then applied iterationCount time, where
the salted secret is the input to the first iteration and

...


Received: from fw2sec.secure.bnl.it (fw2.ntt.it [194.73.95.11]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29417 for <[e-mail]>; Mon, 14 Feb 2000 01:49:28 -0800 (PST)
From: [e-mail]
Received: from mnotes by fw2sec.secure.bnl.it (AIX 4.1/UCB 5.64/4.03) id AA08824; Mon, 14 Feb 2000 10:42:07 +0100
Received: by MNOTES.SECURE.BNL.IT(Lotus SMTP MTA v4.6.2  (693.3 8-11-1998))  id 41256885.00368003 ; Mon, 14 Feb 2000 10:55:17 +0100
X-Lotus-Fromdomain: MULTISERVIZI LAVORO SUD SRL
To: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 14 Feb 2000 10:47:48 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

subscribe




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27334 for <[e-mail]>; Sun, 13 Feb 2000 23:44:24 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id IAA08627; Mon, 14 Feb 2000 08:51:10 +0100
Received: by HYDRA with Microsoft Mail id <01BF76C6.FD06B2A0@HYDRA>; Mon, 14 Feb 2000 08:39:21 +0100
Message-ID: <01BF76C6.FD06B2A0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Magnus (RSA)'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>
Subject: RE: Cert comparison needs AI?
Date: Mon, 14 Feb 2000 08:39:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

>It means that when you form an application, you have to handle this with
>care and make sure that the application don't produce missleading results.

Noop. In the absence of defined semantics, this property or quality MUST be a part
of a valid QC CPS.   The German (QC sample?) CPS must state that you can't compare
German QCs (or do it on your own risk) while the Swedish and Finnish ID-card programs
guarantee that you can trust the static unique ID as being the sole attribute to
compare (after you have detected that the cert really is belonging to these domains).

Note: computer do not "care".  They run algorithms based on a usually limited set of rules.

If the governing humans do not know how to express the rules, the programmers making applications
are likely to fail as well.  As programmers also are humans.  

/anders



/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Sunday, February 13, 2000 13:50
> To: Magnus (RSA); [e-mail]; Stefan Santesson
> Subject: QC: Cert compariosion needs AI?
>
>
> Guys,
>
> >From section 4 security:
>
>    >Comparing two qualified certificates to determine if they
> represent
>    >the same physical entity may provide misleading results
> and should be
>    >performed with care.
>
> Since the relying party is in most cases is a server-computer
> I would be happy to get
> the Java source code for "performed with care".  :-) :-) :-)
>
> Of course a slippery statement like that is not even worth
> the paper it is written on.
> In the "real" world we need down-to-earth solutions which
> means that all this
> is currently completely out of the draft.
>
> Anders
>



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA26843 for <[e-mail]>; Sun, 13 Feb 2000 23:18:11 -0800 (PST)
Received: from HYDRA ([195.198.186.74]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id IAA06387; Mon, 14 Feb 2000 08:24:53 +0100
Received: by HYDRA with Microsoft Mail id <01BF76C3.50D463E0@HYDRA>; Mon, 14 Feb 2000 08:13:03 +0100
Message-ID: <01BF76C3.50D463E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Magnus (RSA)'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Identification confusion continues
Date: Mon, 14 Feb 2000 08:13:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

>Your way of using serialNumber fits well in the QC definition. We could not
>limit the use of serialNumber to a static identifier based on the past
>discussions.

And your way of assigning multiple semantics to an object without having
any disambiguiting element is a practice that usually renders you a kick in the rear in most places of this industry.
To put such constructs in an international standard-to-be is definitely a step up on the penalty ladder.

/Anders



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26370 for <[e-mail]>; Sun, 13 Feb 2000 22:55:54 -0800 (PST)
Received: from stefan (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id HAA31012; Mon, 14 Feb 2000 07:59:10 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Magnus \(RSA\)'" <[e-mail]>, <[e-mail]>
Subject: RE: Cert compariosion needs AI?
Date: Mon, 14 Feb 2000 07:55:00 +0100
Message-ID: <000101bf76b8$69d1a430$6a6fa8c0@stefan>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <000a01bf7620$dbf26470$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

It means that when you form an application, you have to handle this with
care and make sure that the application don't produce missleading results.

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Sunday, February 13, 2000 13:50
> To: Magnus (RSA); [e-mail]; Stefan Santesson
> Subject: QC: Cert compariosion needs AI?
>
>
> Guys,
>
> >From section 4 security:
>
>    >Comparing two qualified certificates to determine if they
> represent
>    >the same physical entity may provide misleading results
> and should be
>    >performed with care.
>
> Since the relying party is in most cases is a server-computer
> I would be happy to get
> the Java source code for "performed with care".  :-) :-) :-)
>
> Of course a slippery statement like that is not even worth
> the paper it is written on.
> In the "real" world we need down-to-earth solutions which
> means that all this
> is currently completely out of the draft.
>
> Anders
>



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26217 for <[e-mail]>; Sun, 13 Feb 2000 22:52:54 -0800 (PST)
Received: from stefan (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id HAA30942; Mon, 14 Feb 2000 07:56:10 +0100
From: "Stefan Santesson" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Magnus \(RSA\)'" <[e-mail]>, <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Indentication confusion continues
Date: Mon, 14 Feb 2000 07:52:01 +0100
Message-ID: <000001bf76b7$ffa2b810$6a6fa8c0@stefan>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <001a01bf75f8$f816db90$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Anders,

Your way of using serialNumber fits well in the QC definition. We could not
limit the use of serialNumber to a static identifier based on the past
discussions.

/Stefan


> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Sunday, February 13, 2000 09:05
> To: Magnus (RSA); [e-mail]; Stefan Santesson
> Subject: QC: Indentication confusion continues
>
>
> Guys,
> After a quick reading of the QC-03 draft I am pretty puzzled.
>
> You have simply renamed dNqualifier into serialNumber.  Where
> did last years endless
> discussion landed?
>
> serialNumber is now made into a name collosion eliminator
> which is a completely different
> task than it has in for example the Swedish and Finnish
> ID-card programs which was one
> of the reasons to switch from dnqualifier.
>
> In those systems serialNumber is a unique identitity and
> other attributes are simply "informative".
>
> You had a number of options to solve this but I can't see any
> traces of this in the draft.
> Of course a CA can define a unique QC statement saying how
> attributes are to be used but that
> is totally redundant and requires proprietary interpretation
> at run-time.
>
> So basically you have "smart-coded" serialNumber into having
> multiple semantics which
> is plain stupid when there are existing attributes like qnQualifier.
>
> Or is it still the "politically correct issues" that haunts
> this draft?.  I.e. that SSN's and similar
> unique identities should not be directly supported  as it
> could be interpreted
> as a recommendation?
>
> Anders



Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17310 for <[e-mail]>; Sun, 13 Feb 2000 15:33:16 -0800 (PST)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA05511 for <[e-mail]>; Mon, 14 Feb 2000 10:35:52 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdmG8m4_; Mon Feb 14 10:35:31 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA12910 for <[e-mail]>; Mon, 14 Feb 2000 10:35:30 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0whEYE; Mon Feb 14 10:34:55 2000
Received: from ntmsg0133.corpmail.telstra.com.au (ntmsg0133.corpmail.telstra.com.au [192.74.168.111]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA18790 for <[e-mail]>; Mon, 14 Feb 2000 10:34:54 +1100 (EST)
Received: by ntmsg0133.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <1WKMW5FK>; Mon, 14 Feb 2000 10:34:35 +1100
Message-ID: <73388857A695D31197EF00508B08F2988A3AD6@NTMSG0131>
From: "Manger, James H" <[e-mail]>
To: "'Roland Mueller'" <[e-mail]>, [e-mail]
Subject: RE: Time-stamping: IETF / ISO
Date: Mon, 14 Feb 2000 10:34:34 +1100
X-MS-TNEF-Correlator: <73388857A695D31197EF00508B08F2988A3AD6@NTMSG0131>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF767A.E264346E"

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

------_=_NextPart_000_01BF767A.E264346E
Content-Type: text/plain;
	charset="iso-8859-1"

Please follow the standard ASN.1 extensibility rules if adding a new field
(e.g. mechanism) to a syntax (e.g. TSTInfo).  That is, the new field must be
added to the end of the SEQUENCE and must be optional.

----------
From:	[e-mail] [mailto:[e-mail]]
Sent:	Friday, 11 February 2000 14:09

..ISO include the mechanism identifiers in their ASN.1 definitions and
specify them with default values..

------_=_NextPart_000_01BF767A.E264346E
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IiQXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0AcCAA4ACgAiACIAAQA2AQEggAMADgAAANAHAgAO
AAoAIgAiAAEANgEBCYABACEAAAA0REE4MUE3RTZBRTJEMzExOTdGOTAwNTA4QjA4RjI5OAAlBwEE
gAEAHgAAAFJFOiBUaW1lLXN0YW1waW5nOiBJRVRGIC8gSVNPAOwIAQ2ABAACAAAAAgACAAEDkAYA
3AcAADQAAAADAN4/r28AAAMAAYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgACgAggBgAA
AAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAAaF
AAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAASACCAGAAAAAADAAAAAAAAA
RgAAAAADhQAAAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAGgAggBgAAAAAA
wAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACYAI
IAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEA
AAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAG
AAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAOgAsgBgAAAAAAwAAAAAAAAEYAAAAA
AIgAAAAAAAALAA+ACyAGAAAAAADAAAAAAAAARgAAAAAFiAAAAAAAAAIBCRABAAAA9gEAAPIBAADQ
AgAATFpGdeWBDacDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQey
ESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFk
MzYWUAunYwEwoCBQbGVhFBAgAhCmbBewB+B0aB2AcwGQDG5kCxEQwFNOLjEuIA7BCfAAkGIDEGl0
cHkgcnUdQAQgBpAgKGFkZAuAZyCgIG4VB9FmCJBsHsAoZS44Zy4gB4AT0QMAc21KKR4AbyERc3kC
MGGCeCHVVFNUSW4CEL4pIiAkABPgBUAEACweA8khSG11HlAgYh2AILHfCYAi4h4SCfAewG8gkB4S
AFNFUVVFTkNF1yCgJ5EmNm8FMGkCIAdAbi4KogqECoAtKtcqFEZtA2E6DIIeAGcLgCDRQCUmQC4f
oG0uBaBtIC5bAMADECLwOix/bV1fKhQGYAIwLBQr0GkekHnFJTAxHyBGZWIgIArADyAAAdAxoDDA
NDowOUEqGi4uSVNPIHBu/mMKQAEAHgMiRyBwAQACMN8GkAiRIGEDoB4RaQXAHuQ/AQELgB/gKbEE
ICjCc3D/BZAGkCAAHhEtgAPwHhA2UvZhIDAFQHYHQApQLQAqBQJ9OfAAAB4AcAABAAAAGgAAAFRp
bWUtc3RhbXBpbmc6IElFVEYgLyBJU08AAAACAXEAAQAAABsAAAABv3TVz7J1xqcE4MAR052CAFCL
Xrv0AGj8KzAAAwAuAAAAAAALACsAAAAAAAsAAgABAAAAHgBCEAEAAAAzAAAAPDczMzg4ODU3QTY5
NUQzMTE5N0VGMDA1MDhCMDhGMjk4ODgzRUM5QE5UTVNHMDEzMT4AAAMA/T/kBAAAQAA5AODENOJ6
dr8BAwDxPwkEAAAeADFAAQAAAAgAAABDNzk5ODc4AAMAGkAAAAAAHgAwQAEAAAAIAAAAQzc5OTg3
OAADABlAAAAAAAMAJgAAAAAAAwA2AAAAAAADAIAQ/////wIBRwABAAAAPAAAAGM9QVU7YT10ZWxl
bWVtbztwPWNvcnBtYWlsO2w9TlRNU0cwMTMxLTAwMDIxMzIzMzQzNFotMTA4OTc1AAIB+T8BAAAA
TgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1URUxTVFJBL09VPVZJQyBNT05BU0gv
Q049UkVDSVBJRU5UUy9DTj1DNzk5ODc4AAAAHgD4PwEAAAAQAAAATWFuZ2VyLCBKYW1lcyBIAB4A
OEABAAAACAAAAEM3OTk4NzgAAgH7PwEAAABOAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAA
AC9PPVRFTFNUUkEvT1U9VklDIE1PTkFTSC9DTj1SRUNJUElFTlRTL0NOPUM3OTk4NzgAAAAeAPo/
AQAAABAAAABNYW5nZXIsIEphbWVzIEgAHgA5QAEAAAAIAAAAQzc5OTg3OABAAAcwig8d4np2vwFA
AAgwbjRk4np2vwEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAAGgAAAFRpbWUtc3RhbXBpbmc6
IElFVEYgLyBJU08AAAAeADUQAQAAADMAAAA8NzMzODg4NTdBNjk1RDMxMTk3RUYwMDUwOEIwOEYy
OTg4QTNBRDZATlRNU0cwMTMxPgAACwApAAAAAAALACMAAAAAAAMABhAJDPBTAwAHEE0BAAADABAQ
AAAAAAMAERACAAAAHgAIEAEAAABlAAAAUExFQVNFRk9MTE9XVEhFU1RBTkRBUkRBU04xRVhURU5T
SUJJTElUWVJVTEVTSUZBRERJTkdBTkVXRklFTEQoRUdNRUNIQU5JU00pVE9BU1lOVEFYKEVHVFNU
SU5GTylUSEFUSQAAAAACAX8AAQAAADMAAAA8NzMzODg4NTdBNjk1RDMxMTk3RUYwMDUwOEIwOEYy
OTg4QTNBRDZATlRNU0cwMTMxPgAAF4I=

------_=_NextPart_000_01BF767A.E264346E--


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09436 for <[e-mail]>; Sun, 13 Feb 2000 09:53:18 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLW5DM>; Sun, 13 Feb 2000 09:48:04 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Marc Jadoul'" <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail], IETF-PXIX <[e-mail]>
Subject: RE: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
Date: Sun, 13 Feb 2000 09:48:04 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Yes, this is possible - you can have two different keys for
a CA, one to sign certs and another to sign CRLs. And yes,
it does work (at least with some of the software out there).
However, these are still both the CAs keys.

There are also "Indirect CRL"s, which can be produced by
one entity saying what is revoked by another entity (a CA).
Not sure how much of the software out there supports that.

Regards,
Ambarish

> -----Original Message-----
> From: Marc Jadoul [mailto:[e-mail]]
> Sent: Sunday, February 13, 2000 5:03 AM
> To: Massimiliano Pala
> Cc: [e-mail]; IETF-PXIX
> Subject: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
> 
> 
> "Salz, Rich" wrote:
> > 
> > >can CRLs be signed by a certificate that is not the CA certificate
> > 
> > No.
> 
> Ok, but may be there is a solution (that i never tried and it might be
> uncompatible with lot of existing software.) :
> 
> If i understand well, you do not want to have your CA keys online for
> security reason ? Or more precisely, you do not want to have some key
> online, because this key is able to sign certificates which would be
> verified by the CA certificate you published ... ?
> 
> But if you generate a second key for your CA, and use this 
> key ONLY for
> signing CRL, you can achieve what you want.
> 
> Of course you need to sign a CA certificate for this new key. This
> certificate would be signed by your main (old) CA key, but 
> you would use
> a keyUsage extension with only the crlSign bit set. Thus this
> certificate can not be used to verify certificates but can be used to
> verify CRLs.
> 
> It would be reasonably safe to have the second CA key online. At least
> it is as safe as what you can get with online signing of revocation
> status.
> 
> Note that you probably also need the keyid extension also to help
> software to find the good CA certificate.
> 
> Let me know if you think it is possible in real life.
> 
> Marc
> 


Received: from online.no (pilt-e.online.no [148.122.208.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04688 for <[e-mail]>; Sun, 13 Feb 2000 06:54:29 -0800 (PST)
Received: from cinet (ti34a64-0247.dialup.online.no [130.67.75.247]) by online.no (8.9.3/8.9.1) with SMTP id PAA29505 for <[e-mail]>; Sun, 13 Feb 2000 15:57:43 +0100 (MET)
Message-ID: <000801bf7632$9da14ee0$f74b4382@cinet>
From: "Tor Rustad" <[e-mail]>
To: <[e-mail]>
Subject: subscribe
Date: Sun, 13 Feb 2000 15:57:14 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF763A.FEB63D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF763A.FEB63D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe


------=_NextPart_000_0005_01BF763A.FEB63D00
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D1>
<P>subscribe</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01BF763A.FEB63D00--



Received: from raptor.globalsign.net (unknown-195-207.eunet.be [195.207.49.1] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03670 for <[e-mail]>; Sun, 13 Feb 2000 04:57:47 -0800 (PST)
Received: from globalsign.net (unverified [213.132.131.117]) by raptor.globalsign.net (Rockliffe SMTPRA 3.4.6) with ESMTP id <[e-mail]>; Sun, 13 Feb 2000 13:00:59 +0000
Sender: mgjadoul
Message-ID: <[e-mail]>
Date: Sun, 13 Feb 2000 14:02:51 +0100
From: Marc Jadoul <[e-mail]>
Organization: BelSign NV/SA
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14pre18 i686)
X-Accept-Language: fr, en, nl
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail], IETF-PXIX <[e-mail]>
Subject: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Salz, Rich" wrote:
> 
> >can CRLs be signed by a certificate that is not the CA certificate
> 
> No.

Ok, but may be there is a solution (that i never tried and it might be
uncompatible with lot of existing software.) :

If i understand well, you do not want to have your CA keys online for
security reason ? Or more precisely, you do not want to have some key
online, because this key is able to sign certificates which would be
verified by the CA certificate you published ... ?

But if you generate a second key for your CA, and use this key ONLY for
signing CRL, you can achieve what you want.

Of course you need to sign a CA certificate for this new key. This
certificate would be signed by your main (old) CA key, but you would use
a keyUsage extension with only the crlSign bit set. Thus this
certificate can not be used to verify certificates but can be used to
verify CRLs.

It would be reasonably safe to have the second CA key online. At least
it is as safe as what you can get with online signing of revocation
status.

Note that you probably also need the keyid extension also to help
software to find the good CA certificate.

Let me know if you think it is possible in real life.

Marc


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02858 for <[e-mail]>; Sun, 13 Feb 2000 03:50:40 -0800 (PST)
Received: from mega (t1o69p66.telia.com [62.20.144.66]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id MAA15172; Sun, 13 Feb 2000 12:57:21 +0100
Message-ID: <000a01bf7620$dbf26470$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Magnus (RSA)" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: QC: Cert compariosion needs AI?
Date: Sun, 13 Feb 2000 12:50:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA02859

Guys,

>From section 4 security:

   >Comparing two qualified certificates to determine if they represent
   >the same physical entity may provide misleading results and should be
   >performed with care.

Since the relying party is in most cases is a server-computer I would be happy to get
the Java source code for "performed with care".  :-) :-) :-)

Of course a slippery statement like that is not even worth the paper it is written on.
In the "real" world we need down-to-earth solutions which means that all this
is currently completely out of the draft. 

Anders




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24093 for <[e-mail]>; Sat, 12 Feb 2000 23:05:18 -0800 (PST)
Received: from mega (t4o69p13.telia.com [62.20.145.133]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id IAA11226; Sun, 13 Feb 2000 08:11:46 +0100
Message-ID: <001a01bf75f8$f816db90$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Magnus (RSA)" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: QC: Indentication confusion continues
Date: Sun, 13 Feb 2000 08:04:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA24094

Guys,
After a quick reading of the QC-03 draft I am pretty puzzled.

You have simply renamed dNqualifier into serialNumber.  Where did last years endless
discussion landed?

serialNumber is now made into a name collosion eliminator which is a completely different
task than it has in for example the Swedish and Finnish ID-card programs which was one
of the reasons to switch from dnqualifier.

In those systems serialNumber is a unique identitity and other attributes are simply "informative".

You had a number of options to solve this but I can't see any traces of this in the draft.
Of course a CA can define a unique QC statement saying how attributes are to be used but that
is totally redundant and requires proprietary interpretation at run-time.

So basically you have "smart-coded" serialNumber into having multiple semantics which
is plain stupid when there are existing attributes like qnQualifier.

Or is it still the "politically correct issues" that haunts this draft?.  I.e. that SSN's and similar
unique identities should not be directly supported  as it could be interpreted
as a recommendation?

Anders



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02684 for <[e-mail]>; Sat, 12 Feb 2000 11:37:16 -0800 (PST)
Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 12JiP5-0003Nf-00 for [e-mail]; Sat, 12 Feb 2000 19:40:27 +0000
Received: from [209.21.28.65] (helo=nma.com) by dfw-mmp3.email.verio.net with esmtp (Exim 3.12 #7) id 12JiOM-0006JO-00 for [e-mail]; Sat, 12 Feb 2000 19:39:43 +0000
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2000 11:39:28 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: announcement ivta.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

List:

Internet voting is a case where privacy must be protected, so that
arguments to justify losing voter privacy in the good name of security
are simply not possible.  Which  firmly posits security  as a protection
of privacy -- not as an enemy of privacy -- in the problem-solving
assumptions to be considered.

In this context, an international team of experts and companies are calling for
open discussions on Internet voting technology. A public founding
assembly will take place February 28 in Washington D.C. at 9 a.m.

Details at http://www.ivta.org

Cheers,

Ed Gerck




Received: from ns1.syntegra.com (ns1.syntegra.com [150.143.16.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09034 for <[e-mail]>; Fri, 11 Feb 2000 21:26:36 -0800 (PST)
Received: from [129.179.17.10] by ns1.cdc.com with ESMTP for [e-mail]; Fri, 11 Feb 2000 23:29:10 -0600
Received: from misty.twntpe.cdc.com by calvin.twntpe.cdc.com for [e-mail]; Sat, 12 Feb 2000 13:29:06 +0800
Reply-To: <[e-mail]>
From: "Ed Greshko" <[e-mail]>
To: <[e-mail]>
Subject: Request for Opinion - LDAP Proxy in a PKI environment
Date: Sat, 12 Feb 2000 13:28:10 +0800
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Hello,

A question has begun to crop up in various places about the suitability of
using an LDAP proxy with caching in a PKI environment.  The particular
environment in question uses CRLs stored in a single LDAP object.

My initial reaction to this is that it would be undesirable to deploy a
proxy with caching.

I'm interested in what views others would have.....

Thanks,
Ed



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27280 for <[e-mail]>; Fri, 11 Feb 2000 15:13:25 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLWYQ7>; Fri, 11 Feb 2000 15:08:10 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Roland Mueller'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time-stamping: IETF / ISO
Date: Fri, 11 Feb 2000 15:08:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Id suggest specifying a complete reference to the 
IETF mechanism(s) in a high-profile, but NON-normative
annex, only.  

 

-----Original Message-----
From: Roland Mueller [mailto:[e-mail]]
Sent: Friday, February 11, 2000 1:17 PM
To: [e-mail]
Cc: Manuel Heras Gilsanz; [e-mail]; [e-mail]
Subject: Re: Time-stamping: IETF / ISO


This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26380 for <[e-mail]>; Fri, 11 Feb 2000 14:48:52 -0800 (PST)
Received: by balinese.baltimore.ie; id WAA27020; Fri, 11 Feb 2000 22:51:59 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma027014; Fri, 11 Feb 00 22:51:42 GMT
Received: from baltimore.ie ([192.168.20.103]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA22884; Fri, 11 Feb 2000 22:51:39 GMT
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2000 22:43:32 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Life is hard, and then you die." <[e-mail]>, Denis Pinkas <[e-mail]>
CC: [e-mail], xme <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id WAA22884
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA26382

Denis, Ronald,

I agree we should align these. However, there's an upcoming 
rev. of CMP (currently being tweaked on the ca-talk list by the
folks who've done the interop), so we do have the option
of adding the TSP values into CMP and moving the colliding
ones. Alternatively, we could add "ranges" into CMP
(not v. extensible though & it wastes bits). I don't
mind which way we do this, but we do need to get rid of
the collisions (and hopefully, prevent future collisions).
Either way, I reckon TSP can stick with its values and CMP can
change.

Regards,
Stephen.

"Life is hard, and then you're acquired:-)" wrote:
> 
> I'm probably a bit late for this, but here goes anyway. I have two
> comments, one related to the failure-info bits, one related to the
> transport mechanisms.
> 
> 1) I'm somewhat unhappy with allocation of values in the
>    PKIFailureInfo definition. Either don't even try to be compatible
>    with CMP (i.e.  just use 0, 1, 2, etc), or then use a different
>    space (e.g. 100, 101, etc). With the current definition the codes
>    conflict with or are intermingled with CMP defined values (it might
>    be a good idea to set a IANA registry for these values, or maybe
>    not).
> 
> 2) The transports are basically the same as 2510, which have been
>    shown to have problems. Two things specifically:
> 
>    A) Is polling needed at all? If so, why doesn't the http transport
>       allow for polling? Either both socket and http should define it,
>       or neither, as they both have similar semantics. Also, if
>       polling is indeed to be supported, some mechanism for connection
>       keep-alive signalling in the socket protocol is needed.
>       Actually, keep-alive signalling might be useful if applications
>       have whole bunches of documents they want timestamped.
> 
>    B) What is the partialMsgRep in the socket protocol good for? The
>       request message contains only single request, and the response
>       message contains a single structure which I don't see how and
>       why you would split up.
> 
>    Because I'm not really sure polling makes much sense here, the
>    easiest things might be to define the socket protocol as just
>    tsaMsg, finalMsgRep, and errorMsgRep, or even just the raw DER
>    encoded message as is done for HTTP (since it's DER encoded the
>    length is available in the first few bytes). Alternatively, reusing
>    the new transports from CMP would allow some folks to reuse
>    existing code (at the expense of extra work for those implementing
>    just TSP) and provide keep-alive signalling for the socket
>    protocol.
> 
>   Cheers,
> 
>   Ronald
> 
> P.S. Minor typo's: "Æ" is used (character 0xC6) instead of "'" in various
>      places.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25746 for <[e-mail]>; Fri, 11 Feb 2000 14:32:39 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA186464; Fri, 11 Feb 2000 17:34:34 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id RAA91824; Fri, 11 Feb 2000 17:35:45 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256882.007C1BB2 ; Fri, 11 Feb 2000 17:35:35 -0500
X-Lotus-FromDomain: IBMUS
To: Roland Mueller <[e-mail]>, [e-mail]
cc: Manuel Heras Gilsanz <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2000 17:16:22 -0500
Subject: Re: Time-stamping: IETF / ISO
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Surely no apology is necessary.  If everyone who produced ASN.1 which
was later revised were considered at fault, no one would use it (which
perhaps would be a good thing, or perhaps not).  However, this leaves open
the question of whether the IETF specification should accomodate the ISO
one somewhat.  First, should the mechanismNotSupported bit be added to
PKIFailureInfo in the PKIX draft?  Second, should the ISO ASN.1 format for
TimeStampReq and TSTInfo be documented in an appendix to the PKIX draft,
pointing out that these are fully compatible with the PKIX definitions
within the existing draft?
     I realize that these suggestions come after last call completion, and
thus may be ruled out of order.

          Tom Gindin


Roland Mueller <[e-mail]> on 02/11/2000 04:16:52 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Manuel Heras Gilsanz <[e-mail]>, [e-mail],
      [e-mail]
Subject:  Re: Time-stamping: IETF / ISO



This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland





Received: from c004.sfo.cp.net (c004-h007.c004.sfo.cp.net [209.228.14.63]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA22951 for <[e-mail]>; Fri, 11 Feb 2000 13:12:25 -0800 (PST)
Received: (cpmta 6452 invoked from network); 11 Feb 2000 13:14:57 -0800
Received: from cs2873-19.austin.rr.com (HELO tuvit.net) (24.28.73.19) by smtp.tuvit.net with SMTP; 11 Feb 2000 13:14:57 -0800
X-Sent: 11 Feb 2000 21:14:57 GMT
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2000 15:16:52 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: Manuel Heras Gilsanz <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Time-stamping: IETF / ISO
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------CC6A994B8F838D97A83974DE"

This is a multi-part message in MIME format.
--------------CC6A994B8F838D97A83974DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland
--------------CC6A994B8F838D97A83974DE
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------CC6A994B8F838D97A83974DE--



Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19019 for <[e-mail]>; Fri, 11 Feb 2000 10:11:08 -0800 (PST)
Received: from ronald.trustpoint.com (ronald.trustpoint.com [192.168.42.4]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id KAA03352 for <[e-mail]>; Fri, 11 Feb 2000 10:14:15 -0800
Received: (from ronald@localhost) by ronald.trustpoint.com (8.8.7/8.8.7) id KAA13271 for [e-mail]; Fri, 11 Feb 2000 10:14:15 -0800
From: "Life is hard, and then you die." <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
To: [e-mail]
Date: Fri, 11 Feb 2000 10:14:15 -0800 (PST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I'm probably a bit late for this, but here goes anyway. I have two
comments, one related to the failure-info bits, one related to the
transport mechanisms.

1) I'm somewhat unhappy with allocation of values in the
   PKIFailureInfo definition. Either don't even try to be compatible
   with CMP (i.e.  just use 0, 1, 2, etc), or then use a different
   space (e.g. 100, 101, etc). With the current definition the codes
   conflict with or are intermingled with CMP defined values (it might
   be a good idea to set a IANA registry for these values, or maybe
   not).

2) The transports are basically the same as 2510, which have been
   shown to have problems. Two things specifically:

   A) Is polling needed at all? If so, why doesn't the http transport
      allow for polling? Either both socket and http should define it,
      or neither, as they both have similar semantics. Also, if
      polling is indeed to be supported, some mechanism for connection
      keep-alive signalling in the socket protocol is needed.
      Actually, keep-alive signalling might be useful if applications
      have whole bunches of documents they want timestamped.

   B) What is the partialMsgRep in the socket protocol good for? The
      request message contains only single request, and the response
      message contains a single structure which I don't see how and
      why you would split up.

   Because I'm not really sure polling makes much sense here, the
   easiest things might be to define the socket protocol as just
   tsaMsg, finalMsgRep, and errorMsgRep, or even just the raw DER
   encoded message as is done for HTTP (since it's DER encoded the
   length is available in the first few bytes). Alternatively, reusing
   the new transports from CMP would allow some folks to reuse
   existing code (at the expense of extra work for those implementing
   just TSP) and provide keep-alive signalling for the socket
   protocol.


  Cheers,

  Ronald


P.S. Minor typo's: "Æ" is used (character 0xC6) instead of "'" in various
     places.



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25428 for <[e-mail]>; Thu, 10 Feb 2000 19:10:41 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA483640; Thu, 10 Feb 2000 22:12:25 -0500
Received: from D51MTA07.pok.ibm.com (d51mta07.pok.ibm.com [9.117.200.35]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id WAA154206; Thu, 10 Feb 2000 22:13:20 -0500
Received: by D51MTA07.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256882.0011B0F9 ; Thu, 10 Feb 2000 22:13:14 -0500
X-Lotus-FromDomain: IBMUS
To: Manuel Heras Gilsanz <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2000 22:08:59 -0500
Subject: Re: Time-stamping: IETF / ISO
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Would it be reasonable to suggest that ISO include the mechanism
identifiers in their ASN.1 definitions and specify them with default values
indicating the IETF standard mechanisms?  This would enable any use of the
IETF definition to interoperate with the ISO definition, without damaging
Roland's proposed definition in any way.
     In any case, I am reasonably sure that no alien race is likely to use
BER or DER with a definition compatible with ours down to the assigned
tags, so interoperation with them will not be affected by the presence or
absence of mechanism identifiers.

          Tom Gindin




Received: from vtools.es (vtools.es [194.179.104.137]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA10875 for <[e-mail]>; Thu, 10 Feb 2000 12:22:34 -0800 (PST)
Received: from vtools.es [192.67.79.8] by vtools.es [194.179.104.190] with SMTP (MDaemon.v2.7.SP5.R) for <[e-mail]>; Thu, 10 Feb 2000 21:39:34 +0100
Sender: manuel
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2000 21:23:39 +0000
From: Manuel Heras Gilsanz <[e-mail]>
Organization: Visual Tools, S.A.
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Time-stamping: IETF / ISO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: [e-mail]
X-Return-Path: [e-mail]

Dear Mr Pinkas,

> Roland,
> 
> Since you said that you want multiple mechanisms to be used and that
> it is NOT the intention of the ISO working group to introduce
> patented mechanisms, would you be able to provide at least one
> useful example of such a binding mechanism that is not patented ?
> 
> Denis

I would like to express some opinions on the management of this draft
with respect to ISO interoperability.

>From my point of view, what ISO is trying to do is to leave the
specification open, so that (in principle) *any* mechanism can be used,
either patented or non-patented. The fact that all the protocols we know
of today are or are not patented (something not at all clear, on the
other hand) is inessential, irrelevant and a pure contingency.

Imagine that we discover life outside Earth and we have to exchange
time-stamp tokens with a (possibly more advanced and therefore
patent-less) civilisation: we don't care whether their TS protocols are
patented or not; what we do is to evaluate the _mechanisms_ for
production of time-stamp tokens they use, and whether they can
interoperate with us. It would be a pity for you to see that aliens can
exchange time-stamps via ISO TS-standard but not via IETF TS-standard!
;-)

As I understand the issue, there is no problem in having several
different time-stamping standards (although this complicates the life of
many people, is inefficient, and creates artificial demand for security
consultants); what is really problematic is to have several
_incompatible_ standards (this should be punished with jail, and with
the death penalty when development of both standards took place in
parallel!!). What ISO is trying to do, from my point of view, is to
minimise the number and the degree of the incompatibilities between IETF
and ISO approaches.

The obstination that you are exercising from your position as IETF draft
editor is totally unacceptable to me. Your decisions should be based on
technical grounds, with the goal of benefiting the whole Internet
community. Don't try to convince us that you discovered two days ago
that ISO is working on a time-stamping standard, because you are also
taking a seat in the ISO working group, and taking good notes of the
discussions held therein.

I have not seen any technical reason why you don't accept ISO approach,
and it is my opinion that as an I-D editor your decisions should be
merely (or, at least, mostly) technical, as opposed to guided by
political or personal interests. The single technical responses of
relevance have been to propose the use the policy field as a way of
choosing the final format (ISO/IETF) of the item, which is other way of
saying "we don't want to be interoperable, you just put another layer on
the onion, and write the format there". (Policy identifiers cannot be
used for that -- nobody has yet agreed how policy identifiers from
different TSA relate, and how to know whether a certain policy-id is ISO
or IETF-oriented.)

Let me finally remind to you that Mr Roland Mueller is not a bored
newcomer suggesting funny changes in the last minute because he doesn't
know what to do in his spare time: he is coordinating the ISO
time-stamping effort, and as such his comments deserve a bit (more) of
attention and dissection on your part. I don't believe in authorities,
but at least we should recognise that his opinions reflect what many
experts have agreed after long, deep discussions, and his motivation is
to promote the compatibility between standards. I think you have
redirected his polite messages to /dev/null as if they came from "just
another one", something very inappropriate from your side. On the other
hand, ISO has been promoting interoperability since its earliest draft,
something I have not seen "from the other side". [Now let me clarify
that I am not a friend of Mr Mueller or part of his family, but I think
he is doing an excellent work as coordinator of the ISO ad-hoc group,
trying to listen to everybody's needs and opinions.]

It is very funny that, being ISO thought of as a "monolythic institution
suffering a lot of bureaucreacy and political influence, where strict
country representation rules govern", and the IETF as "the paradigm of
informal, electronic, open standards without heavy bureaucratic or
political influence, where anyone can participate and an individual can
influence the future of the net" [this is the mental image shared by
many people on both institutions], what we see here is that the "roles"
have been exchanged, and while ISO is warmly promoting easy
interoperation, and dialog, the IETF draft editors coldly find
themselves unable to incorporate the changes due to the proximity of the
closing date or simply dismissing the comments with dubious responses to
which they didn't give a couple of minutes' thought.

I encourage you to reconsider your position, as you might do a great
favour to all the Internet and security communities with the
introduction of the minor changes identified by the ISO working group as
potentially problematic, or at least participating in the dialogue after
leaving the ego at home.

If not in the benefit of human beings, please do it in the benefit of
interoperability with alien civilisations!!

Best regards,

       - Manuel Heras -
     [ I hate flaming, but this was too much! ]

Manuel Heras-Gilsanz
Security Consultant



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04198 for <[e-mail]>; Thu, 10 Feb 2000 07:56:26 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA23172; Thu, 10 Feb 2000 16:59:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2000 16:59:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Simon,

Thanks a lot for your response. However, I do not believe that the
interpretation you make will be the same as the interpretation from
Andreas. :-)

> > Before discussing the modifications or enhancements to be made to
> > OCSP I would like that we go back to the rational of making them.
> >
> > I have not been able to follow in details all the E-mails exchanges
> > on that topic, so if this has already be posted on the mailing list,
> > please indicate me in which message it is mentioned.
> >
> > I would like to go behind arguments like "this is required in
> > specification XXX". I would like to understand the rational of the
> > requirements and, once these are identified, if there would be other
> > solutions that could solve the same requirements.
> 
> > Changing a status in a spec. is an easy thing to do. Before doing
> > anything like this, we (i.e. the WG) have to understand the
> > implications.
> >
> > Once said, let us come to the technical side.
> >
> > It seems to me that the purpose of this new service is to offer an
> > additional guarantee which is that the certificate has really been
> > issued by the right CA and is not a forgery of a certificate made
> > using the CA compromised key.
> 
> This discussion is first and foremost about how to express additional
> assertions in OCSP (apart from revocation) in general, not any particular
> assertion.

A said above: Changing a status in a spec. is an easy thing to do.
Before doing anything like this, we (i.e. the WG) have to understand
the implications. 

> As you say, issuance is not a question if you have the certificate at hand
> and trust the CA certificate. However:

Sorry, this is not what I said. I considered the case of a CA key
compromise. In that case the certificate that you have at hand might
be a forged one, if the CA key has been compromised. So you do not
know whether it comes from the right CA or from the bogus CA.

> Andreas Berger wrote:
> > We had to extend the functionality (it was mid 1998 if I remember
> > correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> > design. We needed (as Hans has written)
> 
> > 1. Certificate was created, is in the service since T,
> > and is not revoked
> > 2. Certificate was created, is in the service since T, and is revoked
> > 3. Certificate is unknown
> 
> > which was not possible with then the OCSP.
> 
> In my understanding "is in service" means that the certificate can be
> produced at one time, but should not be usable until some later time, e.g.
> when the intended user confirms receipt of the corresponding token.

I do interpret "in the service since T" in the same way, so let us
ask the original writer (if he listens to the PKIX mailing list) to
say in a few words what this means, but also ask him to provide the
rational of the requirements that lead to the inclusion of that
sentence.

Denis


> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [e-mail], http://www.iD2tech.com/
> voice [phone], cell [phone], fax [phone]
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03784 for <[e-mail]>; Thu, 10 Feb 2000 07:44:21 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBY24NV>; Thu, 10 Feb 2000 16:46:36 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Thu, 10 Feb 2000 16:46:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> Before discussing the modifications or enhancements to be made to
> OCSP I would like that we go back to the rational of making them.
> 
> I have not been able to follow in details all the E-mails exchanges
> on that topic, so if this has already be posted on the mailing list,
> please indicate me in which message it is mentioned.
> 
> I would like to go behind arguments like "this is required in
> specification XXX". I would like to understand the rational of the
> requirements and, once these are identified, if there would be other
> solutions that could solve the same requirements.

> Changing a status in a spec. is an easy thing to do. Before doing
> anything like this, we (i.e. the WG) have to understand the
> implications.
> 
> Once said, let us come to the technical side. 
> 
> It seems to me that the purpose of this new service is to offer an
> additional guarantee which is that the certificate has really been
> issued by the right CA and is not a forgery of a certificate made
> using the CA compromised key. 

This discussion is first and foremost about how to express additional
assertions in OCSP (apart from revocation) in general, not any particular
assertion. 

As you say, issuance is not a question if you have the certificate at hand
and trust the CA certificate. However:

Andreas Berger wrote:
> We had to extend the functionality (it was mid 1998 if I remember
> correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> design. We needed (as Hans has written)

> 1. Certificate was created, is in the service since T, 
> and is not revoked
> 2. Certificate was created, is in the service since T, and is revoked
> 3. Certificate is unknown

> which was not possible with then the OCSP. 

In my understanding "is in service" means that the certificate can be
produced at one time, but should not be usable until some later time, e.g.
when the intended user confirms receipt of the corresponding token.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999



Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03583 for <[e-mail]>; Thu, 10 Feb 2000 07:41:37 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1460.8) id <1RMGYJKA>; Thu, 10 Feb 2000 10:38:39 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E5623CE@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject: FW: ISS Security Alert v.2
Date: Thu, 10 Feb 2000 10:38:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"

I don't know how many of you are on the ISS mailing list - the information
seemed quite good.

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: David Gerulski [mailto:[e-mail]] 
Sent: Wednesday, February 09, 2000 6:12 PM
To: [e-mail]
Subject: ISS Security Alert v.2



TO UNSUBSCRIBE: email "unsubscribe customerconnect" in the body of your
message to [e-mail].  Contact [e-mail] for
help with any problems!
---------------------------------------------------------------------------

Dear ISS Customer Connect Recipient,

Recent Internet attacks have targeted a number of high-profile Internet
sites such as Yahoo!, Buy.com, E-Bay, Amazon and CNN Interactive.  These
attacks are "Denial-Of-Service" attacks which are designed to bring down an
enterprise network or e-commerce site by flooding it with large amounts of
traffic, similar to hundreds of people repeatedly dialing a telephone number
to keep it busy.

While it is impossible to eliminate all risks from these attacks, Internet
Security Systems (ISS) recommends several steps that you should take if you
find your Internet site is under attack.  ISS also recommends several steps
that you can take before an incident to reduce the risk and possible impact
of these attacks.  

STEPS TO TAKE IF YOU ARE UNDER ATTACK:

*	Assemble an Incident Response Team
*	Get help from ISP and CERT
*	Involve Law Enforcement authorities
*	Monitor systems during the attack

DETAILS:

If you find yourself under attack, stay calm.  Here are 4 concrete steps you
can take to keep control of the situation:

1. Assemble an Incident Response Team.  This team should include senior
technical staff who can help formulate a plan of action, and should have
access to senior management who can authorize the action.  One key role of
this team is to have a contact person to coordinate with other organizations
(e.g. CERT, below) during the incident.

2. Get help.  Contact your Internet Service Provider (ISP) to inform them of
the attack.  It is possible that the ISP can take action to block the
attacks before they reach your computer systems.  Call the Computer
Emergency Response Team (CERT).  You can email them at [e-mail] or fax
them pertinent information at [phone].  You can also contact ISS
at [e-mail].  Include information about:

*	your name, telephone number, email address, and time zone 
*	the name and IP address of the system under attack, 
*	the apparent source of the attack (hostname or IP address)
*	a description of the attack (methods, tools, etc)

3. Contact Law Enforcement authorities to inform them of the incident.  You
may not be the only organization under attack, and they may be able to
provide technical assistance or contacts to help your response efforts.  You
can help the law enforcement efforts by collecting system log information
from target systems.  These logs may be important evidence that law
enforcement needs to take action; it is critical that this information be
collected and protected before it is accidentally (or deliberately) erased. 

4. Monitor important systems during the attack using intrusion detection
software or services.  This can help mitigate the attack, by discovering
actions that can be taken (e.g. installing security patches, expanding RAM
to help the OS to maintain performance during Denial-Of-Service attacks).
It can also help detect signs that this attack is more than a nuisance - for
example, that a Denial-Of-Service attack is a diversion intended to distract
your attention from an actual takeover of your systems.  In particular, if
other organizations are under particular attack, check any of your systems
that might be similar for signs of that attack as well.

STEPS TO TAKE BEFORE AN ATTACK:

*	Identify and empower an Incident Response Team
*	Perform a security audit or risk assessment of critical systems to
                identify risks
*	Mitigate the risks discovered, by installing appropriate security
                software
*	Learn more about Internet security issues

DETAILS:

There are also several things that you can do before an attack that will
greatly improve your ability to respond to an incident:

1. Put together an Emergency Response Plan, and identify a team who will be
responsible for implementing it.  Ensure that the team has senior management
contact, and the necessary technical skills.  The ISS X-Force offers a great
deal of technical information useful for technical staff education at
http://xforce.iss.net/. If these skills are not available in-house, consider
outsourcing this from a company offering Emergency Response Services. ISS'
Emergency Response Services (ERS) are specifically geared to help companies
build and improve upon incident preparedness. This is achieved through
quarterly on site workshops with customers.  This service then helps ISS'
Emergency Response Team be more effective with its 24x7 service in the event
that the client comes under attack.  The Emergency Response Plan should
include an escalation policy, and you should educate your organization on
this policy.

2. Perform an audit of critical business systems, to identify possible
vulnerability to attack.  Take appropriate action to mitigate any identified
risks - for example, by ensuring the Operating System is up-to-date.  This
Security Assessment should include determining any dependencies (like ISP's
and Web hosting companies) and what their protection level is.  It should
also examine network design for security resilience to Denial-Of-Service
attack.  

3. Take action to mitigate risks that are discovered: for example, implement
proper security management infrastructure and applications. (e.g. Intrusion
Detection Systems, Vulnerability Scanning, Firewalls, VPNs, etc). Send
syslog information from your routers to an analysis machine to examine for
evidence of an attack.  By watching for attacks, so you can detect and
respond to them early.  The earlier you detect an incident, the earlier you
can respond to it.  

4. To learn more about Distributed Denial Of Service attacks or about
Internet security issues in general, read the latest ISS X-Force Security
Advisories at http://xforce.iss.net.  In particular, Advisory 43
http://xforce.iss.net/alerts/advise43.php3 discusses these attacks in great
detail.

INFORMATION FOR ISS CUSTOMERS:

On top of developing public security advisories, the ISS X-Force is always
researching, and developing countermeasures within all of our ISS SAFEsuite
and ePatrol Managed Security Service solutions to help protect against
Denial-Of-Service attacks especially from new, high risk attacks such as
Tribe Flood Network and trin00.  ISS customers are advised to ensure that
ISS products are up-to-date: Internet Scanner, System Scanner, and
RealSecure have released Updates to help reduce the risk of these attacks:

SAFEsuite Security Assessment
An Internet Scanner X-press Update is available from
https://www.iss.net/update/InternetScanner/XPressUpdate3_1.xpu

A System Scanner X-Press Update is available from
http://www.iss.net/support/flexchecks/sscanner.php

SAFEsuite Intrusion Detection
An updated version of RealSecure (version 3.2.1) is available from
https://www.iss.net/cgi-bin/download/release/custDown.cgi

For more information on Denial of Service Attacks and a host
of other topics, join us for ISS Connect 2000: International User
Group and Security Summit this March 19th - 24th.

http://connect.iss.net
1-800-416-8749

*******************************************************************
                         ISS CONNECT 2000
International User Group and Information Security Summit
    March 19-24, 2000                  http://connect.iss.net
                          REGISTER TODAY!
*******************************************************************



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00114 for <[e-mail]>; Thu, 10 Feb 2000 05:31:22 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA22316; Thu, 10 Feb 2000 14:34:20 +0100
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2000 14:34:06 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Simon Tardell <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish and Simon,

Before discussing the modifications or enhancements to be made to
OCSP I would like that we go back to the rational of making them.

I have not been able to follow in details all the E-mails exchanges
on that topic, so if this has already be posted on the mailing list,
please indicate me in which message it is mentioned.

I would like to go behind arguments like "this is required in
specification XXX". I would like to understand the rational of the
requirements and, once these are identified, if there would be other
solutions that could solve the same requirements.

Changing a status in a spec. is an easy thing to do. Before doing
anything like this, we (i.e. the WG) have to understand the
implications.

Once said, let us come to the technical side. 

It seems to me that the purpose of this new service is to offer an
additional guarantee which is that the certificate has really been
issued by the right CA and is not a forgery of a certificate made
using the CA compromised key. 

If so, it thus seems to me that the problem that is attempted to be
addressed has to do with the possible compromise of a CA key.
Applying the usual security process leads to the following: this is
a rather seldom event. However, in case of the occurence of that
unlikely event a "disaster recovery plan" is needed and must be
established in advance. This means that usual operations do not
necessarilly need to be encumbered by an additional complexity (or
new protocols) and that the additional complexity should only occur
at the time the event occurs.

I also got the impression that, if this is the problem to be solved,
unless we define an alternative to address the same issue, it could
become MANDATORY to use this additional guarantee, making on-line
queries mandatory (we have all heard recently of denial of service
attacks).

I would first like to make sure that this understanding is correct.
Is it ?

Regards,

Denis

> > Hi Simon,
> >     You describe the situation very well. If I were trying to provide
> > additional semantics, I would do them through extensions.
> 
> Thanks, Ambarish. If this is the intention behind RFC2560 [model 2) below]
> then then perhaps a clarification should be made to the RFC. This to avoid
> several OCSP profiles that are mutually incompatible.
> 
> There are a couple of points that come to mind: The last few paragraphs of
> 3.2 where the possible certificate status values are described indicate that
> "good" means "cert is not revoked" && good_A && good_B ... and that the
> answer MAY be qualified by extensions. That is contradicting what you just
> said (since CertStatus would not be orthogonal to the extensions). On the
> other hand it does not say that "revoked" means "cert is revoked" || bad_A
> || bad_B ... In other words, the definition of "good" and "revoked" are not
> the positive and negative answers to the same question!
> 
> In addition, "unknown" should perhaps be redefined as "the responder does
> not have enough information to answer the question" to remove all doubt.
> 
> > For example,
> > if a client wanted to know whether a cert was issued or not, in
> > addition to its revocation status, I would recommend putting that
> > additional status information in singleExtensions, rather than
> > trying to overload the meaning of good.
> 
> Now, I think there are fairly good arguments for model 1). In the end, what
> matters if it is ok to use the certificate or not, the reason may really
> vary, but is of less importance to whoever is refusing service as a result
> of the reply. In model 2) you would put an equivalence between "error -- I
> don't understand what it says here" and "no, you can't do that". But the
> important message is the "no, you can't do that" not the "because ...", so
> making the "because ..." part critical seems unnecessary. Also, you would
> loose the distinction between "if you don't understand why you can't do
> that, it doesn't matter, just don't" and "you really should understand
> this". The latter is an exceptional condition while the former is not.
> Treating exceptional conditions (unhandled critical extensions) as a normal
> condition would require a quite clear wording about this in the RFC to make
> sure all clients understand the semantics in the same way.
> 
> But, either model is fine with me, as long as a clear choice is made in the
> RFC.
> 
> > The issue of whether a cert was ever issued or not, did come up, but
> > the group concensus was that a client either had the cert in hand and
> > could verify the signature on the cert and so know whether it was
> > issued or not.
> >
> > If the CA's cert signing key was compromised and you wanted to deal
> > with that case, you need to either directly trust the OCSP responder
> > and ask it about the CA's self signed cert, or check the CA's cert
> > if it is part of a larger hierarchy, or try to deal with the issue in
> > an out of band way.
> 
> Agreed. However, "issuance" has a slightly different semantics in the German
> specs. The certificate may not be valid for use until some time after its
> actual production (an unknown amount of time). That property needs to be
> answered by a German OCSP responder.
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [e-mail], http://www.iD2tech.com/
> voice [phone], cell [phone], fax [phone]
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999
> 
> > > Ambarish wrote:
> > >
> > > >     There are ways of profiling the spec that work within the
> > > > parameters defined by OCSP. In other ways, you break the design
> > > > of the basic protocol. In my opinion, this is the latter, not
> > > > the former.
> > >
> > > The German requirements raise the question what would be the "canonical"
> way
> > > of extending OCSP. This is not quite clear to me from reading the RFC.
> In my
> > > mind the scope of OCSP is to answer binary status queries on
> certificates
> > > (good, bad and possibly "don't know"). The natural question to ask is
> that
> > > of revocation. The Germans need to answer that of issuance. Still more
> can
> > > be imagined.
> > >
> > > In RFC2560 CertificateStatus can be set to "good", "revoked" or
> "unknown".
> > > The wording is a bit unclear here: Does "unknown" mean that "I don't
> know
> > > whether this certificate is revoked" or "I know this certificate does
> not
> > > exist"? The Germans seem to have opted for the latter interpretation.
> Now,
> > > assuming the former interpretation we have three answers to the
> revocation
> > > question (good, bad, don't know). How do we extend OCSP to assert the
> answer
> > > to other questions? I see two possible approaches:
> > >
> > > 1)
> > > CertificateStatus is generalized so that it contains the logical sum of
> all
> > > properties that the client wants to have asserted (or that the responder
> > > wants to assert in response to a query). E.g. assume two properties A
> and B
> > > that both have to be "good" for a certificate to be valid for use, then
> > > CertificateStatus is "good" if both of them are "good", "bad" if (at
> least)
> > > one of them is "bad" unless one of them is "unknown" in which case
> > > CertificateStatus is "unknown". Extensions to the respective statuses
> can be
> > > used to qualify the answer (e.g. to tell _what_ properties were bad), if
> the
> > > client really cares.
> > >
> > > 2)
> > > CertificateStatus is defined to only provide good, bad and unknown
> answers
> > > to the revocation question. SingleExtensions are defined for each
> property
> > > (except for revocation status) and each such SingleExtension can take
> the
> > > value "good", "bad" and "unknown". The problem then arises that the
> client
> > > can perhaps not be expected to understand new properties (extensions) as
> > > they are implemented on the server. To solve that, these extensions
> should
> > > be marked critical if they are "bad" or "unknown", but not if they are
> > > "good".
> > >
> > > Now, this is not quite what it says in the RFC (for example, the answer
> > > "good" allows to be qualified with other types of goodness, but there is
> > > seemingly no way to answer "not revoked, but bad in some other sense").
> The
> > > former method seems more attractive from the perspective that it allows
> > > making the clients simpler, but it would require some changes to the
> current
> > > protocol. The latter solution would work with current clients (how
> widely
> > > deployed are they anyway?) but is less appealing (an error in the client
> > > would have the meaning "no, you can't do that"...).


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07408 for <[e-mail]>; Wed, 9 Feb 2000 16:23:13 -0800 (PST)
Received: from stefan (www.naval.se [193.12.72.53] (may be forged)) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id BAA11765 for <[e-mail]>; Thu, 10 Feb 2000 01:26:10 +0100
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Subject: New draft profile for Qualified Certificates
Date: Thu, 10 Feb 2000 01:22:22 +0100
Message-ID: <000801bf735c$e6aa2900$6a6fa8c0@stefan>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <[e-mail]>

All,

We have submitted a new, and hopefully final, draft profile for Qualified
Certificates.

In this draft we have included the consensus from the latest intensive
discussions.

I would like to draw the attention to the fact that there are some
substantial changes in this document which includes:
- The personalData solution is removed from the draft
- Use of subjectDirectoryAttributes extension is added as replacement.
- The pseudonym attribute has got a new standard OID (X.520)
- dnQualifier is replaced with the serialNumber attribute

In addition to this there are some minor changes and ASN.1 updates.

Due to a broken link error in the IETF web page, you must follow this URL to
find the new draft (the current pointer on the IETF page is pointing to the
old non-existing draft)

http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-03.txt

At this moment I don't know of any unsolved issues.

/Stefan



Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21086 for <[e-mail]>; Wed, 9 Feb 2000 02:08:03 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBY22VH>; Wed, 9 Feb 2000 11:10:17 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Wed, 9 Feb 2000 11:10:34 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> Hi Simon,
>     You describe the situation very well. If I were trying to provide
> additional semantics, I would do them through extensions. 

Thanks, Ambarish. If this is the intention behind RFC2560 [model 2) below]
then then perhaps a clarification should be made to the RFC. This to avoid
several OCSP profiles that are mutually incompatible.

There are a couple of points that come to mind: The last few paragraphs of
3.2 where the possible certificate status values are described indicate that
"good" means "cert is not revoked" && good_A && good_B ... and that the
answer MAY be qualified by extensions. That is contradicting what you just
said (since CertStatus would not be orthogonal to the extensions). On the
other hand it does not say that "revoked" means "cert is revoked" || bad_A
|| bad_B ... In other words, the definition of "good" and "revoked" are not
the positive and negative answers to the same question! 

In addition, "unknown" should perhaps be redefined as "the responder does
not have enough information to answer the question" to remove all doubt.

> For example,
> if a client wanted to know whether a cert was issued or not, in
> addition to its revocation status, I would recommend putting that
> additional status information in singleExtensions, rather than
> trying to overload the meaning of good.

Now, I think there are fairly good arguments for model 1). In the end, what
matters if it is ok to use the certificate or not, the reason may really
vary, but is of less importance to whoever is refusing service as a result
of the reply. In model 2) you would put an equivalence between "error -- I
don't understand what it says here" and "no, you can't do that". But the
important message is the "no, you can't do that" not the "because ...", so
making the "because ..." part critical seems unnecessary. Also, you would
loose the distinction between "if you don't understand why you can't do
that, it doesn't matter, just don't" and "you really should understand
this". The latter is an exceptional condition while the former is not.
Treating exceptional conditions (unhandled critical extensions) as a normal
condition would require a quite clear wording about this in the RFC to make
sure all clients understand the semantics in the same way.

But, either model is fine with me, as long as a clear choice is made in the
RFC.

> The issue of whether a cert was ever issued or not, did come up, but
> the group concensus was that a client either had the cert in hand and
> could verify the signature on the cert and so know whether it was
> issued or not.
> 
> If the CA's cert signing key was compromised and you wanted to deal
> with that case, you need to either directly trust the OCSP responder
> and ask it about the CA's self signed cert, or check the CA's cert
> if it is part of a larger hierarchy, or try to deal with the issue in
> an out of band way.

Agreed. However, "issuance" has a slightly different semantics in the German
specs. The certificate may not be valid for use until some time after its
actual production (an unknown amount of time). That property needs to be
answered by a German OCSP responder. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999


> > Ambarish wrote:
> > 
> > >     There are ways of profiling the spec that work within the
> > > parameters defined by OCSP. In other ways, you break the design
> > > of the basic protocol. In my opinion, this is the latter, not
> > > the former.
> > 
> > The German requirements raise the question what would be the "canonical"
way
> > of extending OCSP. This is not quite clear to me from reading the RFC.
In my
> > mind the scope of OCSP is to answer binary status queries on
certificates
> > (good, bad and possibly "don't know"). The natural question to ask is
that
> > of revocation. The Germans need to answer that of issuance. Still more
can
> > be imagined.
> > 
> > In RFC2560 CertificateStatus can be set to "good", "revoked" or
"unknown".
> > The wording is a bit unclear here: Does "unknown" mean that "I don't
know
> > whether this certificate is revoked" or "I know this certificate does
not
> > exist"? The Germans seem to have opted for the latter interpretation.
Now,
> > assuming the former interpretation we have three answers to the
revocation
> > question (good, bad, don't know). How do we extend OCSP to assert the
answer
> > to other questions? I see two possible approaches:
> > 
> > 1)
> > CertificateStatus is generalized so that it contains the logical sum of
all
> > properties that the client wants to have asserted (or that the responder
> > wants to assert in response to a query). E.g. assume two properties A
and B
> > that both have to be "good" for a certificate to be valid for use, then
> > CertificateStatus is "good" if both of them are "good", "bad" if (at
least)
> > one of them is "bad" unless one of them is "unknown" in which case
> > CertificateStatus is "unknown". Extensions to the respective statuses
can be
> > used to qualify the answer (e.g. to tell _what_ properties were bad), if
the
> > client really cares.
> > 
> > 2)
> > CertificateStatus is defined to only provide good, bad and unknown
answers
> > to the revocation question. SingleExtensions are defined for each
property
> > (except for revocation status) and each such SingleExtension can take
the
> > value "good", "bad" and "unknown". The problem then arises that the
client
> > can perhaps not be expected to understand new properties (extensions) as
> > they are implemented on the server. To solve that, these extensions
should
> > be marked critical if they are "bad" or "unknown", but not if they are
> > "good".  
> > 
> > Now, this is not quite what it says in the RFC (for example, the answer
> > "good" allows to be qualified with other types of goodness, but there is
> > seemingly no way to answer "not revoked, but bad in some other sense").
The
> > former method seems more attractive from the perspective that it allows
> > making the clients simpler, but it would require some changes to the
current
> > protocol. The latter solution would work with current clients (how
widely
> > deployed are they anyway?) but is less appealing (an error in the client
> > would have the meaning "no, you can't do that"...).



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14031 for <[e-mail]>; Tue, 8 Feb 2000 09:44:35 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLWNPP>; Tue, 8 Feb 2000 09:39:04 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Simon Tardell'" <[e-mail]>, "'Andreas Berger'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Tue, 8 Feb 2000 09:39:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Simon,
    You describe the situation very well. If I were trying to provide
additional semantics, I would do them through extensions. For example,
if a client wanted to know whether a cert was issued or not, in
addition to its revocation status, I would recommend putting that
additional status information in singleExtensions, rather than
trying to overload the meaning of good.

We went through a long discussion on how best to do this when OCSP
was being defined and figured that the best way of keeping the spec
clean, was to have a very specific meaning for status, which is just
revocation status.

The issue of whether a cert was ever issued or not, did come up, but
the group concensus was that a client either had the cert in hand and
could verify the signature on the cert and so know whether it was
issued or not.

If the CA's cert signing key was compromised and you wanted to deal
with that case, you need to either directly trust the OCSP responder
and ask it about the CA's self signed cert, or check the CA's cert
if it is part of a larger hierarchy, or try to deal with the issue in
an out of band way.

Hope this helps,
Regards,
Ambarish 

> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Tuesday, February 08, 2000 2:26 AM
> To: 'Ambarish Malpani'; 'Andreas Berger'
> Cc: '[e-mail]'
> Subject: RE: German Law and OCSP
> 
> 
> Ambarish wrote:
> 
> >     There are ways of profiling the spec that work within the
> > parameters defined by OCSP. In other ways, you break the design
> > of the basic protocol. In my opinion, this is the latter, not
> > the former.
> 
> The German requirements raise the question what would be the 
> "canonical" way
> of extending OCSP. This is not quite clear to me from reading 
> the RFC. In my
> mind the scope of OCSP is to answer binary status queries on 
> certificates
> (good, bad and possibly "don't know"). The natural question 
> to ask is that
> of revocation. The Germans need to answer that of issuance. 
> Still more can
> be imagined.
> 
> In RFC2560 CertificateStatus can be set to "good", "revoked" 
> or "unknown".
> The wording is a bit unclear here: Does "unknown" mean that 
> "I don't know
> whether this certificate is revoked" or "I know this 
> certificate does not
> exist"? The Germans seem to have opted for the latter 
> interpretation. Now,
> assuming the former interpretation we have three answers to 
> the revocation
> question (good, bad, don't know). How do we extend OCSP to 
> assert the answer
> to other questions? I see two possible approaches:
> 
> 1)
> CertificateStatus is generalized so that it contains the 
> logical sum of all
> properties that the client wants to have asserted (or that 
> the responder
> wants to assert in response to a query). E.g. assume two 
> properties A and B
> that both have to be "good" for a certificate to be valid for 
> use, then
> CertificateStatus is "good" if both of them are "good", "bad" 
> if (at least)
> one of them is "bad" unless one of them is "unknown" in which case
> CertificateStatus is "unknown". Extensions to the respective 
> statuses can be
> used to qualify the answer (e.g. to tell _what_ properties 
> were bad), if the
> client really cares.
> 
> 2)
> CertificateStatus is defined to only provide good, bad and 
> unknown answers
> to the revocation question. SingleExtensions are defined for 
> each property
> (except for revocation status) and each such SingleExtension 
> can take the
> value "good", "bad" and "unknown". The problem then arises 
> that the client
> can perhaps not be expected to understand new properties 
> (extensions) as
> they are implemented on the server. To solve that, these 
> extensions should
> be marked critical if they are "bad" or "unknown", but not if they are
> "good".  
> 
> Now, this is not quite what it says in the RFC (for example, 
> the answer
> "good" allows to be qualified with other types of goodness, 
> but there is
> seemingly no way to answer "not revoked, but bad in some 
> other sense"). The
> former method seems more attractive from the perspective that 
> it allows
> making the clients simpler, but it would require some changes 
> to the current
> protocol. The latter solution would work with current clients 
> (how widely
> deployed are they anyway?) but is less appealing (an error in 
> the client
> would have the meaning "no, you can't do that"...).
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [e-mail], http://www.iD2tech.com/
> voice [phone], cell [phone], fax [phone]
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999
> 


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01797 for <[e-mail]>; Tue, 8 Feb 2000 02:24:27 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBYH8G7>; Tue, 8 Feb 2000 11:26:34 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Andreas Berger'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Tue, 8 Feb 2000 11:26:28 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish wrote:

>     There are ways of profiling the spec that work within the
> parameters defined by OCSP. In other ways, you break the design
> of the basic protocol. In my opinion, this is the latter, not
> the former.

The German requirements raise the question what would be the "canonical" way
of extending OCSP. This is not quite clear to me from reading the RFC. In my
mind the scope of OCSP is to answer binary status queries on certificates
(good, bad and possibly "don't know"). The natural question to ask is that
of revocation. The Germans need to answer that of issuance. Still more can
be imagined.

In RFC2560 CertificateStatus can be set to "good", "revoked" or "unknown".
The wording is a bit unclear here: Does "unknown" mean that "I don't know
whether this certificate is revoked" or "I know this certificate does not
exist"? The Germans seem to have opted for the latter interpretation. Now,
assuming the former interpretation we have three answers to the revocation
question (good, bad, don't know). How do we extend OCSP to assert the answer
to other questions? I see two possible approaches:

1)
CertificateStatus is generalized so that it contains the logical sum of all
properties that the client wants to have asserted (or that the responder
wants to assert in response to a query). E.g. assume two properties A and B
that both have to be "good" for a certificate to be valid for use, then
CertificateStatus is "good" if both of them are "good", "bad" if (at least)
one of them is "bad" unless one of them is "unknown" in which case
CertificateStatus is "unknown". Extensions to the respective statuses can be
used to qualify the answer (e.g. to tell _what_ properties were bad), if the
client really cares.

2)
CertificateStatus is defined to only provide good, bad and unknown answers
to the revocation question. SingleExtensions are defined for each property
(except for revocation status) and each such SingleExtension can take the
value "good", "bad" and "unknown". The problem then arises that the client
can perhaps not be expected to understand new properties (extensions) as
they are implemented on the server. To solve that, these extensions should
be marked critical if they are "bad" or "unknown", but not if they are
"good".  

Now, this is not quite what it says in the RFC (for example, the answer
"good" allows to be qualified with other types of goodness, but there is
seemingly no way to answer "not revoked, but bad in some other sense"). The
former method seems more attractive from the perspective that it allows
making the clients simpler, but it would require some changes to the current
protocol. The latter solution would work with current clients (how widely
deployed are they anyway?) but is less appealing (an error in the client
would have the meaning "no, you can't do that"...).

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01214 for <[e-mail]>; Mon, 7 Feb 2000 09:48:43 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18037 for <[e-mail]>; Mon, 7 Feb 2000 09:51:28 -0800 (PST)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA01781 for <[e-mail]>; Mon, 7 Feb 2000 12:51:21 -0500 (EST)
Received: from sun.com (edgemont [129.148.75.133]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id MAA13557 for <[e-mail]>; Mon, 7 Feb 2000 12:51:24 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2000 12:48:53 -0500
From: Yassir Elley <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Question on KeyIdentifier chaining
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a question about the chaining of SubjectKeyIdentifiers and AuthorityKeyIdentifiers.
Although RFC2459 and the son-of-RFC2459 both RECOMMEND application support
for the authority and subject key identifier extensions, neither document clearly specifies
under what circumstances, if any, should the application reject a certification path based on
invalid key identifier chaining.

The Basic Certificate Processing section very explicitly talks about unique identifier
chaining, but it does not mention key identifier chaining.
About unique identifier chaining, it states:

(5) [Verify that] The certificate issuer unique identifier is the
         working_issuer_UID, meaning:
            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or
            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

I was wondering whether these same rules apply to key identifier chaining.
In other words, should we have a step like:
(6) [Verify that] The certificate authority key identifier is the
         working_AKI, meaning:
            (i) working_AKI is non-null and matches the value in
            the authorityKeyIdentifier field, or
            (ii) working_AKI is null and the authorityKeyIdentifier field is
            not present.

It is unclear to me whether the key identifiers are just meant to FACILITATE
chain building, or whether they are actually meant to be enforced in path validation.
In other words, if an application is presented the following certpath, should the application
reject the cert path because the key identifiers don't chain properly (i.e. Certificate 1
does not have a subject key identifier, but Certificate 2 does have an authority key
identifier)? Alternatively, should the application just treat the key identifiers as hints 
and accept the cert path if  everything else checks out (i.e. the signatures and everything
else, other than the key identifiers, chain properly)?

Certificate 1:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: not present

Certificate 2:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=A
SKI: not present

Or what about this chain, where the key identifiers are both present but they don't match?
Should the application reject this chain even though the signatures and everything else,
other than the key identifiers, chain properly.

Certificate 3:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: present, value=A

Certificate 4:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=B
SKI: not present

I do realize that Certificate 1 is not a PKIX-conformant since it is a CA certificate
which does not contain a SubjectKeyIdentifier extension, but there may be cases
where certpaths contain both conformant and non-conformant certificates.

Thanks in advance,
Yassir.


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14971 for <[e-mail]>; Mon, 7 Feb 2000 00:11:14 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA17454; Mon, 7 Feb 2000 09:13:47 +0100
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2000 09:13:43 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Roland Mueller <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, Robert Zuccherato <[e-mail]>, Mike Matyas <[e-mail]>, Stuart Haber <[e-mail]>, Jean-Jaques Quisquater <[e-mail]>, Xuejia Lai <[e-mail]>, Mike Chawrun <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> Denis,
> 
> let me clarify our position:
> 
> It is NOT the intention of the ISO working group to introduce patented
> mechanisms, our approach is to allow for MULTIPLE mechanism to be used
> for time stamping. 

Roland,

Since you said that you want multiple mechanisms to be used and that
it is NOT the intention of the ISO working group to introduce
patented mechanisms, would you be able to provide at least one
useful example of such a binding mechanism that is not patented ?

Denis

> That's why we introced a mechanism identifier. This
> ISO draft does NOT suggest the IETF use or endorse any other mechanism,
> it is just for interoperability reasons.
> 
> We are also trying to have common data structures to achieve a common
> base that allows for further extensions (for the IETF and the ISO
> protocols) of time stamping protocols but may be used for schemes as
> already introduced in part 2 of our working draft.
> 
> I hope that this clarifies our requested changes.
> 
> Roland
> 
>   --------------------------------------------------------------------
> 
>   Mueller, Roland <[e-mail]>
>   TUVIT Inc.
> 
>   Mueller, Roland
>   TUVIT Inc.                                            <[e-mail]>
>   8716 North MoPac Suite 220;Austin;Texas;78759;U.S.A.  Télécopie: [phone]
>                                                         Bureau: [phone]


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14692 for <[e-mail]>; Mon, 7 Feb 2000 00:03:30 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id JAA09178; Mon, 7 Feb 2000 09:06:10 +0100
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2000 09:06:06 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John, 

Your text addition is fine and I have no problem to add it to the
Security considerations section.

"If different entities obtain timestamps on the same data object
using the same hash algorithm, or a single entity obtains multiple
timestamps on the same object, the generated timestamp tokens will
include identical message imprints; as a result, an observer with
access to those timestamp tokens could infer that the timestamps may
refer to the same underlying data."

Denis
 
> Denis wrote, excerpting:
> 
> > Let us address the three technical points raised by John first:
> >
> > JL1: "If different entities obtain timestamps on the same data
> > object using the same hash algorithm, or a single entity obtains
> > multiple timestamps on the same object, the generated timestamp
> > tokens will include identical message imprints; as a result, an
> > observer could determine that the timestamps refer to the same
> > underlying data.  It might be worth a note in Security
> > Considerations stating that, in contexts where this potential
> > exposure is a concern, some unique value could be generated by the
> > requester and combined with a data object before hashing the
> > combination in order to produce MessageImprint's hashedMessage."
> >
> > An observer could indeed determine that the timestamps refer to the
> > same underlying data. However, this is not a big concern since the
> > observer will neither know the actual content nor the intended
> > usage. The way that is proposed to address this issue might lead to
> > the definition of another standardized binding technique so that the
> > receiver of the TSP can know how to verify the linkage. I am not in
> > favor of defining such a new linkage structure under the reason that
> > I do not find the problem sufficiently important to be corrected. I
> > would rather prefer to address the concern in a different way: if
> > the requester really cares about this problem, he should rather use
> > a protected channel with data confidentiality to access the TSA. If
> > you wish to provide some text along these lines, I would be willing
> > to consider it for inclusion in the security consideration section.
> >
> 
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine. I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
> 
> --jl
> 
>


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09151 for <[e-mail]>; Sat, 5 Feb 2000 12:08:00 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLW2C4>; Sat, 5 Feb 2000 12:02:35 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Mirko Tedaldi'" <[e-mail]>, Ilan Shacham <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Sat, 5 Feb 2000 12:02:33 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Mirko,
    Most commercial software does not remove expired, revoked
certs from their CRLs, but there have already been requests
for that behavior. Expect to see it in CA products this year.

Regards,
Ambarish

> -----Original Message-----
> From: Mirko Tedaldi [mailto:[e-mail]]
> Sent: Wednesday, February 02, 2000 6:36 AM
> To: Ilan Shacham
> Cc: [e-mail]
> Subject: RE: OCSP and CSL
> 
> 
> At 14.30 02/02/00 +0200, Ilan Shacham wrote:
> 
> >Section 3.3 of RFC 2459 clearly states:
> >         An entry may be removed from
> >    the CRL after appearing on one regularly scheduled CRL 
> issued beyond
> >    the revoked certificate's validity period.
> >
> >If you want to validate an "old" signature, all you have to do is
> >retrive the crl that was in order at the time of the signature, to
> >see if the certificate was valid at the time.
> 
> About it, do you know how commercial PKI softwares work? Do 
> they remove 
> expired certificates from CRL ?
> 
> Mirko Tedaldi.
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08647 for <[e-mail]>; Sat, 5 Feb 2000 11:53:40 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLW2BX>; Sat, 5 Feb 2000 11:48:05 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Joerg Seidel'" <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Sat, 5 Feb 2000 11:48:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA08648

Hi Joerg,
    No, this isn't a security flaw - PKIX requires a revoked
cert to appear in at least 1 CRL before it is dropped of the
CRL list because of expiry - somebody already thought of
this one!

Regards,
Ambarish

> -----Original Message-----
> From: Joerg Seidel [mailto:[e-mail]]
> Sent: Thursday, February 03, 2000 5:12 AM
> To: Massimiliano Pala
> Cc: [e-mail]
> Subject: Re: OCSP and CSL
> 
> 
> Massimiliano Pala schrieb:
> > 
> > Irene Gassko wrote:
> > >
> > > >2. once a cert is inserted into a CRL, it can *never* be
> > > >deleted from it
> > >
> > > This is not true. Expired certificates are deleted from CRL.
> > 
> > I am not sure about this. If you delete it from the list how you can
> > prove it is not valid from the revokation date on ??? The 
> CRLs should
> > provide an 'history' of all revoked certificates...
> 
> In order to prove the invalidity of a certain signature you 
> need the CRL of
> the point of time the signature was made. Well, more 
> precisely the CRL which
> was released next after the signature was made. If you want 
> to be able to
> prove the validity of a signature after the expiration date of the
> corresponding certificate you need to store this CRL together with the
> signature. Well and you need to prove the validity of the
> CRL-Signing-Certificate at that time, so you need ... and so 
> on until you are
> got a CRL signed with a private key corresponding to a non-expired and
> non-revoked certificate.
> 
> I just realized: Maybe there is a small security flaw in this 
> system: If a
> certificate gets revoked just before certificate expiration, 
> but the next CRL
> is released after the expiration time, the revocation might 
> not been stated in
> CRLs at all. The state of the signature is unknown.
> 
> Jörg Seidel
> -- 
> timeproof                               phone  [phone]
> Development                             fax    [phone]
> Harburger Schloßstraße 6-12             mailto:[e-mail]
> D-21079 Hamburg                         http://www.timeproof.de
> 
>      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +
> 


Received: from c004.sfo.cp.net (c004-h005.c004.sfo.cp.net [209.228.14.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA25436 for <[e-mail]>; Fri, 4 Feb 2000 13:44:02 -0800 (PST)
Received: (cpmta 16279 invoked from network); 4 Feb 2000 13:46:03 -0800
Received: from cs2889-175.austin.rr.com (HELO tuvit.net) (24.28.89.175) by smtp.tuvit.net with SMTP; 4 Feb 2000 13:46:03 -0800
X-Sent: 4 Feb 2000 21:46:03 GMT
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2000 15:47:57 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, Wes Doonan <[e-mail]>, "Jose A. Ma~n" <[e-mail]>, Robert Zuccherato <[e-mail]>, Mike Matyas <[e-mail]>, Stuart Haber <[e-mail]>, Jean-Jaques Quisquater <[e-mail]>, Xuejia Lai <[e-mail]>, Mike Chawrun <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------6E20372CE9B681C67E22FE5F"

This is a multi-part message in MIME format.
--------------6E20372CE9B681C67E22FE5F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

let me clarify our position:

It is NOT the intention of the ISO working group to introduce patented
mechanisms, our approach is to allow for MULTIPLE mechanism to be used
for time stamping. That's why we introced a mechanism identifier. This
ISO draft does NOT suggest the IETF use or endorse any other mechanism,
it is just for interoperability reasons.

We are also trying to have common data structures to achieve a common
base that allows for further extensions (for the IETF and the ISO
protocols) of time stamping protocols but may be used for schemes as
already introduced in part 2 of our working draft.

I hope that this clarifies our requested changes.

Roland
--------------6E20372CE9B681C67E22FE5F
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------6E20372CE9B681C67E22FE5F--



Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11696 for <[e-mail]>; Fri, 4 Feb 2000 09:15:55 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA10529 for <[e-mail]>; Fri, 4 Feb 2000 09:14:35 -0800 (PST)
Received: from netscape.com ([206.222.244.15]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP id FPF1DV00.EHX; Fri, 4 Feb 2000 09:17:55 -0800 
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2000 09:17:57 -0800
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn John" <[e-mail]>
CC: "'Denis Pinkas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Reguarding the security concerns around identical MessageImprint values:

I agree that text describing this issue would be useful.  While the problem will
not be a concern for many who use this protocol, describing the it in the
Security Considerations section will keep at least one implementor from creating
an application that does not provide the desired security.

You might also consider suggesting a way to address the problem in particular
applications.  Creating the MessageImprint from data that contains a salt value,
and the original document nicely avoids this problem.  This type of solution can
be implemented by applications that require it.  There is no need to add it to
the timestamping protocol.

Terry

"Linn, John" wrote:

> Denis wrote, excerpting:
>
> > Let us address the three technical points raised by John first:
> >
> > JL1: "If different entities obtain timestamps on the same data
> > object using the same hash algorithm, or a single entity obtains
> > multiple timestamps on the same object, the generated timestamp
> > tokens will include identical message imprints; as a result, an
> > observer could determine that the timestamps refer to the same
> > underlying data.  It might be worth a note in Security
> > Considerations stating that, in contexts where this potential
> > exposure is a concern, some unique value could be generated by the
> > requester and combined with a data object before hashing the
> > combination in order to produce MessageImprint's hashedMessage."
> >
> > An observer could indeed determine that the timestamps refer to the
> > same underlying data. However, this is not a big concern since the
> > observer will neither know the actual content nor the intended
> > usage. The way that is proposed to address this issue might lead to
> > the definition of another standardized binding technique so that the
> > receiver of the TSP can know how to verify the linkage. I am not in
> > favor of defining such a new linkage structure under the reason that
> > I do not find the problem sufficiently important to be corrected. I
> > would rather prefer to address the concern in a different way: if
> > the requester really cares about this problem, he should rather use
> > a protected channel with data confidentiality to access the TSA. If
> > you wish to provide some text along these lines, I would be willing
> > to consider it for inclusion in the security consideration section.
> >
>
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine. I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
>
> --jl
>
>



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08865 for <[e-mail]>; Fri, 4 Feb 2000 07:45:58 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiayp02370; Fri, 4 Feb 2000 15:48:22 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14119; Fri, 4 Feb 00 10:45:40 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA19477; Fri, 4 Feb 2000 10:48:21 -0500
Date: Fri, 4 Feb 2000 10:48:21 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Joerg" == Joerg Seidel <[e-mail]> writes:

 Joerg> "Linn, John" schrieb:
 >> I don't think that a confidentiality-protected channel to the TSA
 >> solves the issue I was envisioning.  I expect that some uses of
 >> timestamps will require that their recipients present or post them
 >> (selectively or generally) for examination after they're obtained,
 >> and that such timestamps could potentially be correlated by third
 >> parties.  I might be interested, e.g., to observe a timestamp
 >> obtained by someone else with a hash which matches that of a
 >> confidential document of mine.
 Joerg> I don't think that this really matters in pratical life, since
 Joerg> a timestamp without the corresponding document wouldn't proof
 Joerg> anything. I can not imagine an application which makes it
 Joerg> necessary to send a timestamp without the document.

I suppose it isn't entirely obvious what sort of hazards are created
by the scenarion John mentioned.  On the other hand, it is clear that
what John described is accurate: if you have two timestamps with the
same imprint, the conclusion that they are for the same document
follows automatically.

Consider the analogy of ECB encryption -- this is considered unwise
because of the property that the occurrence of the same cipher block
means the same plaintext was encrypted.  Does that matter?  Often, it
doesn't.  Sometimes it might.  Since it's trivially avoided (by using
any other mode), ECB is considered a thing to avoid.

While one might argue about the importance of adding the note John
asked for, is there harm in adding it?  Does it mislead?  I don't see
that it does.  It provides information that may only matter to a very
few, but since it does, let's add it.

	paul



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08406 for <[e-mail]>; Fri, 4 Feb 2000 07:39:58 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiayo25170; Fri, 4 Feb 2000 15:42:15 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA13968; Fri, 4 Feb 00 10:39:34 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA19468; Fri, 4 Feb 2000 10:42:14 -0500
Date: Fri, 4 Feb 2000 10:42:14 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Linn," == Linn, John <[e-mail]> writes:

 Linn,> I don't think that a confidentiality-protected channel to the
 Linn,> TSA solves the issue I was envisioning.  I expect that some
 Linn,> uses of timestamps will require that their recipients present
 Linn,> or post them (selectively or generally) for examination after
 Linn,> they're obtained, and that such timestamps could potentially
 Linn,> be correlated by third parties.  I might be interested, e.g.,
 Linn,> to observe a timestamp obtained by someone else with a hash
 Linn,> which matches that of a confidential document of mine. I'm not
 Linn,> committed to proposing a particular mechanism; I suggest,
 Linn,> however, slightly adapting text above into an advisory note
 Linn,> for Security Considerations: "If different entities obtain
 Linn,> timestamps on the same data object using the same hash
 Linn,> algorithm, or a single entity obtains multiple timestamps on
 Linn,> the same object, the generated timestamp tokens will include
 Linn,> identical message imprints; as a result, an observer with
 Linn,> access to those timestamp tokens could infer that the
 Linn,> timestamps may refer to the same underlying data."

I support John's reasoning.  The proposed note sounds good.  (I'd
suggest dropping "may" from the last line, since the hash is supposed
to have low probability of collisions.)

	paul


Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06492 for <[e-mail]>; Fri, 4 Feb 2000 06:45:17 -0800 (PST)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <PAA03796> (multiple receipients); Fri, 4 Feb 2000 15:47:45 +0100 (MET)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id PAA22633; Fri, 4 Feb 2000 15:47:16 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2000 15:53:08 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'Denis Pinkas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

"Linn, John" schrieb:
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine.
I don't think that this really matters in pratical life, since a timestamp
without the corresponding document wouldn't proof anything. I can not imagine
an application which makes it necessary to send a timestamp without the
document. But if you are transmitting/publishing the document together with
the timestamp, the third party would be looking for the document not the hash
since it can even recognize it when small changes were made.

> I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
As stated above I do not believe this to be necessary, but I don't have an
objection either.

Jörg Seidel

-- 
timeproof                               phone  [phone]
Development                             fax    [phone]
Harburger Schloßstraße 6-12             mailto:[e-mail]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +


Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA05627 for <[e-mail]>; Fri, 4 Feb 2000 06:09:49 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Feb 2000 14:09:30 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA01413; Fri, 4 Feb 2000 09:10:46 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <1F90RY8T>; Fri, 4 Feb 2000 09:13:35 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Fri, 4 Feb 2000 09:20:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis wrote, excerpting:

> Let us address the three technical points raised by John first:
> 
> JL1: "If different entities obtain timestamps on the same data
> object using the same hash algorithm, or a single entity obtains
> multiple timestamps on the same object, the generated timestamp
> tokens will include identical message imprints; as a result, an
> observer could determine that the timestamps refer to the same
> underlying data.  It might be worth a note in Security
> Considerations stating that, in contexts where this potential
> exposure is a concern, some unique value could be generated by the
> requester and combined with a data object before hashing the
> combination in order to produce MessageImprint's hashedMessage."
> 
> An observer could indeed determine that the timestamps refer to the
> same underlying data. However, this is not a big concern since the
> observer will neither know the actual content nor the intended
> usage. The way that is proposed to address this issue might lead to
> the definition of another standardized binding technique so that the
> receiver of the TSP can know how to verify the linkage. I am not in
> favor of defining such a new linkage structure under the reason that
> I do not find the problem sufficiently important to be corrected. I
> would rather prefer to address the concern in a different way: if
> the requester really cares about this problem, he should rather use
> a protected channel with data confidentiality to access the TSA. If
> you wish to provide some text along these lines, I would be willing
> to consider it for inclusion in the security consideration section.
> 

I don't think that a confidentiality-protected channel to the TSA solves the
issue I was envisioning.  I expect that some uses of timestamps will require
that their recipients present or post them (selectively or generally) for
examination after they're obtained, and that such timestamps could
potentially be correlated by third parties.  I might be interested, e.g., to
observe a timestamp obtained by someone else with a hash which matches that
of a confidential document of mine. I'm not committed to proposing a
particular mechanism; I suggest, however, slightly adapting text above into
an advisory note for Security Considerations: "If different entities obtain
timestamps on the same data object using the same hash algorithm, or a
single entity obtains multiple timestamps on the same object, the generated
timestamp tokens will include identical message imprints; as a result, an
observer with access to those timestamp tokens could infer that the
timestamps may refer to the same underlying data."

--jl

 


Received: from felix.intertex.se ([195.22.82.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29902 for <[e-mail]>; Fri, 4 Feb 2000 02:56:57 -0800 (PST)
Date: Fri, 4 Feb 2000 11:59:11 +0100
Message-Id: <[e-mail]>
X-Sender: mats@pop3
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: Mats Hansson <[e-mail]>
Subject: Comment on RFC 2459: Validity time type

Dear Sirs,

I have a comment on clause 4.1.2.5: "Validity" in the RFC 2459. Most
probably, you have already had similar comments, but anyway:

Why is it not allowed to use the GeneralizedTime format for validity dates
before 2050? Why not use the next 50 years gradually allowing and
encouraging CA's and clients to switch over to a time format more suitable
for the future? The present spec. preserves the two-digit limitation and it
is not until some years before 2050 that PKI/security software will get the
real test that they are treating the four-digit representation properly.
Will we see a "close-to-2050"-bug then, all over the world, just like the
millenium-bug?

My suggestion is to allow the GeneralizedTime type now already. Or at least
start allowing it after a known date, say year 2005. So software will have a
chance to be modified. Sooner or later, we (programmers) will face the
"real" test.

Kindest regards
Mats Hansson

Mats Hansson
Intertex Data AB
Rissneleden 45
174 44 Sundbyberg
Sweden

Tel [phone]    Fax [phone]    www: http://www.intertex.se



Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29399 for <[e-mail]>; Fri, 4 Feb 2000 02:29:30 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA18232; Fri, 4 Feb 2000 11:32:15 +0100
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2000 11:31:57 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On January the 25 th Warwick Ford, co-chair of the PKIX WG, issued a
14-days WG Last Call on the document
draft-ietf-pkix-time-stamp-05.txt.

The last call period will thus end on February the 8 th.

Up to now, several comments and responses have been posted to the
mailing list by Roland Mueller, Michael Zolotarev, Magnus Nystrom,
Peter Gutmann, Paul Koning, John Linn and Philip Hallam-Baker.

As lead editor of the document I will attempt to summarize the
comments that have been received so far.

Roland, as editor of an ISO document on time stamping (WD 18014) is
asking for an extremely late and major change in the document. The
rational advocated for that change request is to accommodate
particular mechanisms that do not use digital signatures.

Paul asked for an example to justify added stuff and Roland produced
a 5 pages text, ... which did not convinced Paul for making the
change. Roland did not replied up to now.

John raised three technical comments (I will answer to them later
below) and pointed a few editorial errors (thanks John !).

Philip discussed on the first technical points raised by John.

Peter asked for the removal of some ASN1 tags. Magnus supported this
position.

Let us address the three technical points raised by John first:

JL1: "If different entities obtain timestamps on the same data
object using the same hash algorithm, or a single entity obtains
multiple timestamps on the same object, the generated timestamp
tokens will include identical message imprints; as a result, an
observer could determine that the timestamps refer to the same
underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential
exposure is a concern, some unique value could be generated by the
requester and combined with a data object before hashing the
combination in order to produce MessageImprint's hashedMessage."

An observer could indeed determine that the timestamps refer to the
same underlying data. However, this is not a big concern since the
observer will neither know the actual content nor the intended
usage. The way that is proposed to address this issue might lead to
the definition of another standardized binding technique so that the
receiver of the TSP can know how to verify the linkage. I am not in
favor of defining such a new linkage structure under the reason that
I do not find the problem sufficiently important to be corrected. I
would rather prefer to address the concern in a different way: if
the requester really cares about this problem, he should rather use
a protected channel with data confidentiality to access the TSA. If
you wish to provide some text along these lines, I would be willing
to consider it for inclusion in the security consideration section.


JL2: "The second paragraph of Sec. 2.2 bears a number of SHALLs for
verification steps which are to be performed by the requesting
entity once the TimeStampToken is received.  What's the recommended
or required action if any of these verifications fail? "

Here is the text:

Upon receiving the response (which is or includes a TimeStampResp,
as defined below), the requesting entity SHALL verify the status
error 
returned in the response and if no error is present it SHALL verify
the
various fields contained in the TimeStampToken and the validity of
the 
digital signature of the TimeStampToken. In particular, it SHALL
verify
that what was time stamped corresponds to what was requested to be 
time stamped.  The requester SHALL verify that the TimeStampToken
contains the correct certificate identifier of the TSA, the correct 
data imprint and the correct hash algorithm OID.  It SHALL then
verify 
the timeliness of the response by verifying either the time included 
in the response against a local trusted time reference, if one is 
available, and/or the value of the nonce (large random number with a 
high probability that it is generated by the client only once) 
included in the response against the value included in the request.

I propose to add: "If any of the verifications above fails, the
TimeStampToken SHALL be rejected."

JL3: "In the Accuracy structure, is no more than one of the seconds,
millis, or micros OPTIONALs to occur, or may more than one of these
elements occur in combination? "

If you want to express, e.g. 1,5 s you have to use two of them in
combination. However, I suspect that in practice this case will be
quite seldom, but in theory any value must be able to be expressed.

Now let us come back to the main issue raised by Roland. Since, I
have shown up in an ISO ad-hoc meeting on Time Stamping that was
held on the last day of the RSA conference in San Jose, I know a
little bit more than what has been exposed.

I will wear two hats in sequence:

1) to express my own opinion,
2) to act as a moderator in the discussion.

My own opinion first: 

I cannot agree more with Roland when he says: " It is understood
that this proposal reaches the IETF working group at an extremely
late stage in its standardisation cycle." 

The main idea seems to open the door to "binding schemes" that do
not use digital signatures. The single one that I know is the
patented scheme from Surety. It has been advocated that other
schemes could also fall under that umbrella, but, up to now, no one
has yet advertised an unpatented scheme. It would thus seem that the
motivation of the change is to allow similar ASN1 structures to be
used for content of the Time Stamp Token, whatever binding scheme is
being used; in practice, the (unpatended) scheme from the PKIX WG
and at least one patented scheme from Surety.

My position as a moderator:

I am awaiting for other comments or opinions on that topic before
trying to see where the WG concensus is.

Denis.


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04608 for <[e-mail]>; Thu, 3 Feb 2000 11:10:45 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLWC0J>; Thu, 3 Feb 2000 11:05:17 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Andreas Berger'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Thu, 3 Feb 2000 11:05:17 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Andreas,
    Does it really make sense calling this OCSP any more? You will
most probably not work with most of the servers/clients.

    Also, you do have the requirement that the client verifies the
public key hash that it receives in the response...

    There are ways of profiling the spec that work within the
parameters defined by OCSP. In other ways, you break the design
of the basic protocol. In my opinion, this is the latter, not
the former.

Regards,
Ambarish

P.S. If you can get the German standard changed to follow the
spec, that might not be a very bad idea.

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Andreas Berger [mailto:[e-mail]]
> Sent: Monday, January 31, 2000 5:19 AM
> To: Ambarish Malpani
> Cc: '[e-mail]'
> Subject: Re: German Law and OCSP
> 
> 
> Ambarish Malpani wrote:
> > 
> > Hi Guys,
> >     I recently read a document that seemed to indicate that
> > the German Digital Signature Law or some related documents
> > specified that you can use OCSP to check the revocation status
> > of a cert, but they allowed you to send over all 0's as the
> > hash of the CA's public key.
> 
> This is true. We introduced this option to enable the 
> end-system to make
> queries about certificates when the CA certificate is not (at least at
> the point of this check) known. Therefore, we allowed to "omit" the CA
> public key (resp. the hash) in the query. The hash is, of course,
> required in the reply.
> 
> >     Does anybody know more about whether the statement above
> > is true or not? If it is, I am concened that they might not be
> > using OCSP correctly.
> 
> We had to extend the functionality (it was mid 1998 if I remember
> correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> design. We needed (as Hans has written)
> 
> 1. Certificate was created, is in the service since T, and is not
> revoked
> 2. Certificate was created, is in the service since T, and is revoked
> 3. Certificate is unknown
> 
> which was not possible with then the OCSP.
> 
> Andreas Berger
> GMD Darmstadt
> -- 
> Keine Zeit haben wir genug!
> 


Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02276; Thu, 3 Feb 2000 09:37:15 -0800 (PST)
From: [e-mail]
Subject: Latest Jonah code now available
To: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.2a  November 23, 1999
Message-ID: <[e-mail]>
Date: Thu, 3 Feb 2000 12:38:37 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/03/2000 12:37:47 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     The latest snapshot of the Jonah code is available from
http://www.foobar.com/jonah.
     This code should also be available from http://web.mit.edu/pfl soon.
This release is
     available internationally.

     Jonah is a open source implementation written by IBM and its
subsidiaries Lotus and Iris.
     It currently implements a subset of the IETF PKIX standards (
RFC-2459, RFC-2510,
     RFC-2511, and RFC-2587).

     There was a paper published in the 8th USENIX Security Symposium
Proceedings
     on Jonah. A copy of the paper can be found at
http://www.foobar.com/papers/usenix-jonah.html.

     Discussion of Jonah takes place on the [e-mail] mailing list.
An archive of this list
     can be found at http://www.imc.org/imc-pfl.

     This code should not be considered a complete work, although it is the
last major
     drop that we plan on doing. Some of the code has gotten a lot more
attention then
     others. For example, the GUI has fallen behind some of the other
pieces of code.
     We hope that this becomes a community effort to help maintain this
code, and
     people well supply  comments, bug fixes, and new features.


                              Mike







Received: from aci01-internal.americancentury.com ([e-mail] [207.19.50.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28394 for <[e-mail]>; Thu, 3 Feb 2000 07:02:22 -0800 (PST)
Received: by aci01-internal.americancentury.com; id JAA02333; Thu, 3 Feb 2000 09:04:47 -0600 (CST)
Received: from laptop-1.americancentury.com(10.122.30.128) by aci01.americancentury.com via smap (4.1) id xma002323; Thu, 3 Feb 00 09:04:46 -0600
From: "Robert Rowland" <[e-mail]>
To: "Joerg Seidel" <[e-mail]>, "Massimiliano Pala" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP and CSL
Date: Thu, 3 Feb 2000 09:03:11 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

Is it possible that these problems be divided into two different needs:
1) real time authentication-> vpn technologies,
2) long term authentication->wills, contracts,....


The need for verification of valid certs three years ago sems moot if the
purpose is/was used for corporate remote dial-in,
versus the need to assure that my signature on my will is not used to give
Anna Nicole
Smith any more money.

?????

-----Original Message-----
From: Joerg Seidel [mailto:[e-mail]]
Sent: Thursday, February 03, 2000 5:12 AM
To: Massimiliano Pala
Cc: [e-mail]
Subject: Re: OCSP and CSL


Massimiliano Pala schrieb:
>
> Irene Gassko wrote:
> >
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> > This is not true. Expired certificates are deleted from CRL.
>
> I am not sure about this. If you delete it from the list how you can
> prove it is not valid from the revokation date on ??? The CRLs should
> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL
of
the point of time the signature was made. Well, more precisely the CRL
which
was released next after the signature was made. If you want to be able
to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until
you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If
a
certificate gets revoked just before certificate expiration, but the
next CRL
is released after the expiration time, the revocation might not been
stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel
--
timeproof                               phone  [phone]
Development                             fax    [phone]
Harburger Schloßstraße 6-12             mailto:[e-mail]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +



Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27220 for <[e-mail]>; Thu, 3 Feb 2000 06:20:58 -0800 (PST)
Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis29.marconicomms.com (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]>; Thu, 03 Feb 2000 14:20:37 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-19) id NAA15761; Thu, 3 Feb 2000 13:57:47 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 8025687A.004CAD18 ; Thu, 3 Feb 2000 13:57:30 +0000
X-Lotus-FromDomain: MCSUB2@MCEXT
From: "Duncan Deborde" <[e-mail]>
Sender: "Duncan Deborde" <[e-mail]>
To: Joerg Seidel <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 3 Feb 2000 13:57:05 +0000
Subject: Re: OCSP and CSL
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA27264

Jörg Seidel wrote

> I just realized: Maybe there is a small security flaw in this system: If a
> certificate gets revoked just before certificate expiration, but the next CRL
> is released after the expiration time, the revocation might not been stated in
> CRLs at all. The state of the signature is unknown.

RFC2459 states: "An entry may be removed from  the CRL after appearing on one
regularly scheduled CRL issued beyond the revoked certificate's validity
period."

Assuming this implies the entry must be present for the next CRL after the
expiration time, this situation you propose will not arise.


Duncan de Borde







Received: from mbox.theo.it (mbox.theo.it [193.76.75.218]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27241 for <[e-mail]>; Thu, 3 Feb 2000 06:22:25 -0800 (PST)
Received: from mirko (137.204.186.190) by mbox.theo.it with ESMTP (Eudora Internet Mail Server 2.2); Thu, 3 Feb 2000 15:29:14 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Thu, 03 Feb 2000 15:25:43 +0100
To: Joerg Seidel <[e-mail]>
From: Mirko Tedaldi <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 14.12 03/02/00 +0100, Joerg Seidel wrote:
>I just realized: Maybe there is a small security flaw in this system: If a
>certificate gets revoked just before certificate expiration, but the next CRL
>is released after the expiration time, the revocation might not been stated in
>CRLs at all. The state of the signature is unknown.

I don't think it is a flaw. A revoked certificate must be always issued in 
CRLs, even if it is expired at the moment of issuing CRL. Actually, RFC 
2459 states that a exipired certificate may be removed just "after 
appearing on one regularly scheduled CRL."

Mirko Tedaldi.



Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25526 for <[e-mail]>; Thu, 3 Feb 2000 05:04:38 -0800 (PST)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <OAA17031> (multiple receipients); Thu, 3 Feb 2000 14:07:00 +0100 (MET)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id OAA16056; Thu, 3 Feb 2000 14:06:30 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2000 14:12:22 +0100
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Massimiliano Pala schrieb:
> 
> Irene Gassko wrote:
> >
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> > This is not true. Expired certificates are deleted from CRL.
> 
> I am not sure about this. If you delete it from the list how you can
> prove it is not valid from the revokation date on ??? The CRLs should
> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL of
the point of time the signature was made. Well, more precisely the CRL which
was released next after the signature was made. If you want to be able to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If a
certificate gets revoked just before certificate expiration, but the next CRL
is released after the expiration time, the revocation might not been stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel
-- 
timeproof                               phone  [phone]
Development                             fax    [phone]
Harburger Schloßstraße 6-12             mailto:[e-mail]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25246 for <[e-mail]>; Thu, 3 Feb 2000 04:57:35 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBYHCQ8>; Thu, 3 Feb 2000 13:59:21 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>
Cc: [e-mail]
Subject: RE: More on OCSP and CSL
Date: Thu, 3 Feb 2000 13:59:04 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

 
> Antonio Lioy wrote:
>  
> > This is another view: the CSL is being used as a waiting
> > list for possibly revoked certs. If it is later revoked,
> > then you'll put it in the CRL, otherwise you'll remove it
> > from the CSL.
> > 
> > But I disagree with this view: if I temporarily lost control
> > of my smart-card, I can never know what has happened during
> > that period of time.
> 
> Yes, but I think that if you are not sure about some misusage
> of the private key, then you should request it to be revoked.
> 
> This is for two reasons: the first is about how long a CSL will
> become if we keep track about every suspension of certificates
> and the second is about your trusting in your key-pair.

> If we keep every suspension tracked on the CSL, it can get a
> very long list and it could suffer from problems related to
> this aspect (distribution, definition of delta's CSL, and so
> on... ). I'd like to avoid these problems as them tend to
> get the CSL more complex than needed.

Your CSLs will of course suffer from the same problems as CRLs but worse.
However this is only a problem if regularly transfer all of the list (CSL or
CRL) from a CA somewhere. 

The whole idea of having a _periodically_ updated list of the current status
of the database of the CA is to me a rather ridiculous attempt of modelling
an old technology solution to a problem using new technology, NOT solving
the problem with the new technology. (The old technology solution is of
course the printed books that merchants used to check your card against.)
Serializations of the database are needed when you need to transport all of
the data from the CA to somewhere, e.g. to startup the cache of a validation
authority -- other certificate status consumers should only care about the
status of the certificates involved in the operation they are about to
perform (that's why we have OCSP).

Finally, I do realize that issuing CRLs periodically is convenient from an
implementor's perspective (because that's what I am), but following the
arguments above I think it is unhealthy to mandate that nextUpdate _always_
be set in a CRL (like RFC2459 does).
 
> The second aspect is related on the fact that if you do not
> trust your key for a certain period, than you should not trust
> it at all because it could be open to every kind of attacks:
> let's say someone discovers your password and uses it non only
> when it is suspended, but he/her can get in touch with your key
> during the working time when you are having a coffe-break...
> 
> If you are now trusting your key it is possible you think that
> the 5 mins of a coffe break do not represent a real danger...
> 
> So my vision is: if you trust your certificate is because it has
> never been in danger, if there is a possibility your certificate
> (read key-pair) has been compromised (so it con be compromised
> again...) either if you are not sure about it, than you should
> revoke it...
[...]
> Once a key/pair has been compromised (or possibily compromised)
> it should not, to me, being trusted any more.

Well, if you have a smart card the idea is that your typical office pick
pocket, teenage son or whatever is the most common wallet poacher type, does
not have access to a tunneling microscope or some other equipment to extract
the keys from the card. So, it would suffice to change PIN code of the card
once you regain physical possession of the card to be able to trust the keys
from that moment on.

If you allow reestablishing trust in a smart card token that way or not is
again a policy question. But given the manufacturing cost of a smart card, I
think it is not unlikely that some CAs would.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24773 for <[e-mail]>; Thu, 3 Feb 2000 04:31:18 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id NAA07755; Thu, 3 Feb 2000 13:33:00 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2000 13:34:58 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Irene Gassko <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF9DEB266365B773EC75AB37B"

This is a cryptographically signed message in MIME format.

--------------msF9DEB266365B773EC75AB37B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Irene Gassko wrote:
> 
> At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> >Juan Rodriguez-Torrent wrote:
> >[snip]
> >I'm mildly unsatisfied of the recent discussion over this
> >list. It appears that everybody is against certificate
> >suspension, given its associated cost. I think that, when
> >speaking technically, we should abide from the associated
> >costs of operation, because those costs are quite sensitive
> >to the perceived needs from the users (otherwise we would
> >never define or adopt strong security measures because they
> >are surely too expensive :-)
> >Moreover, some mails suggest to use CRL with the OnHold
> >reason for suspension, and later remove the certificate if
> >it is not actually revoked. What??? I have some really bad
> >feeling about this solution because my understanding is:
> >1. "revoked" means revoked, i.e. the cert is no more valid
> >for any use starting from a certain date
> 
> If we look for a real world analogy here, I would expect that it
> would be instructive to see how credit card companies handle it.
> Most will close your account forever, but when I called AMEX
> and asked them to close my account, they told me that within
> a year I could reopen it if I changed my mind. Hence this is at
> least debatable.
> 
> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
> 
> This is not true. Expired certificates are deleted from CRL.

I am not sure about this. If you delete it from the list how you can
prove it is not valid from the revokation date on ??? The CRLs should
provide an 'history' of all revoked certificates...

C'you,

	Massimiliano Pala ([e-mail])
--------------msF9DEB266365B773EC75AB37B
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMjAzMTIzNDU4WjAjBgkqhkiG9w0BCQQxFgQUTsF5vBMgmZIi+EjppcFykAYwzwAw
DQYJKoZIhvcNAQEBBQAEgYAns6A1LwN/BAJWi1Tg8oysMmssuAwvestAGb+7Qv1/gv9BS9Zr
/TvBxfc+q//oWkL/f0ziLlckoMcTu5/sFw8rivcW2gT7Bh1FMJ1PMMc3/6DbmdgXzAI6Gbq+
6B+bWHPI0wrU7VJeRp1m+LkPhJV77R1IKISsRQw3ycwA1Kg4Cg==
--------------msF9DEB266365B773EC75AB37B--



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24184 for <[e-mail]>; Thu, 3 Feb 2000 04:21:41 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id NAA07176; Thu, 3 Feb 2000 13:23:00 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2000 11:44:13 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juan Rodriguez-Torrent <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]> <006901bf6c77$ebe93320$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5ACAEAB8B9A96F71546AFBEF"

This is a cryptographically signed message in MIME format.

--------------ms5ACAEAB8B9A96F71546AFBEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juan Rodriguez-Torrent wrote:
> 
> So on Friday I "suspend" my cert ... how do I do that? signing with the cert
> I want to suspend? calling a help desk ($$)? ... and then on Monday how do I
> activate my cert? Another phone call ($$)? signing a request with the
> suspended cert? Oh! I forgot the one time token! But who would trust that
> "one time token" left on an insecure office next to the vacationing certs? I
> claim it would have no trust associated... unless I carry it with me and
> then why not carry the original cert that I'm trying to suspend and avoid
> all the hassle? Maybe I should get an additional cert so I can suspend and
> activate the one cert I want to leave in my office during the weekend? Does
> any of this makes any business sense?

The mechanisms of supension/revoking/re-validation are up to the organization:
some organizations could simply require a signed form to suspend the certificate
and/or using an additional code given to the user at the issuing time, others
could accept it on the phone... etc... I think this is something related to
organizations' policy.

On the certificate suspension/re-validation: if the user trusts again the
certificate (see my previous today mails) than he/she can ask for re-validation,
if this is not the case (he/she do not trust is) the revokation is requested.
I think it is up to the user (or you can simply decide to use the suspension
mechanism when someone asks for revokation to avoid time delays between
the request and the real revokation).

> The smart card example is another example on how we are so desperately
> trying to change business processes that actually work. Does anyone leave
> their passport, driver license, credit card or checkbook in and untrusted
> area for a weekend?

I usually don't. But what if you loose it ?? Or simply you can not remember
where it is ??? We should consider these cases either...
 
> Have you considered the costs of involved in this "let's give our certs the
> week-end off"? In a large office hiring certsitting personnel could be much
> cheaper than all those convoluted motions I see proposed for trivial
> reasons. No one in their right state of mind leaves the ATM card, credit
> card or any financial relevant document seating in an insecure office over
> the weekend for the pleasure of it.

You should trust the certificate-sitters ... and what if them sign contracts for
$millions??? You do not have any mechanism to state you were not using it (not
everyone uses smartcards, I think the majority of certificates are simply stored
on removable medias (floppy, CD, Zip, etc... ) as smartcards are not so widely
available... not everywhere at least).

C'you,

	Massimiliano Pala ([e-mail])
--------------ms5ACAEAB8B9A96F71546AFBEF
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMjAzMTA0NDEzWjAjBgkqhkiG9w0BCQQxFgQUeyJoG8i4f1zQFeKyJVUGlPvf58gw
DQYJKoZIhvcNAQEBBQAEgYDCLa1fD1TrhqrXoJcbzdKj51tHSAWRLOS1CDx0QLj5tPhfoNTT
rsr/tcAfcdlbb+CcnsXZhA2LLpPEkz/W9CvQq8KCY1wbhVPeeZloDdhj8+G3ZsfBWJuRY10R
lGsI0y4Phd5BLMM9Rtr+fbSRz6PoTX33lfPKpNEnzgnoh83CoA==
--------------ms5ACAEAB8B9A96F71546AFBEF--





Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24153 for <[e-mail]>; Thu, 3 Feb 2000 04:21:34 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id NAA07165; Thu, 3 Feb 2000 13:22:47 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2000 11:22:27 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juan Rodriguez-Torrent <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]> <001901bf6b6e$db9653e0$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6DF0605447C7FE6DE0D98344"

This is a cryptographically signed message in MIME format.

--------------ms6DF0605447C7FE6DE0D98344
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juan Rodriguez-Torrent wrote:
> 
> Massimiliano, the issue of suspension was discussed several times during the
> last few years and the bottom line is that nobody was able to show a
> reasonable business case for it. In other words, there is not enough
> interest in suspension mechanisms to generate income or help sales of a
> specific PKI because of that feature. I'm sure the additional complexity
> that Russ brings to our attention would be less of a deterrent if someone
> was willing to make suspension mechanisms attractive to the vendors. Let's
> not forget the ISVs (Independent Software Vendors) that have to add yet
> another level of complexity to their products to enable suspension and they
> also have to be convinced. Also, let's not forget the additional complexity
> to be stated on the policies with the corresponding legal issues arising
> from that added feature.  I could go on for a while on that subject but I
> think you got my point.

I know, adding complexity is never a feature... at least when that complexity is
not needed. My thinking about it are very clear... we need something to provide
such service ...

> Let me add that the reason you stated for having a certificate suspension
> list is trivial and raises fundamental questions:
> 
> 1. If the CA is offline WHO WOULD create the suspension list?

The OCSP server could do that as it is a trusted suorce of information and it
have to keep track of the 'validity' of the certificates. So you can retrieve
the certificate status by getting the OCSP response about it, or just get the
CSL/CRL pair in this case you'll know exaclty wich certificates are suspended
and/or revoked).

> 2. Since without a trusted authority a suspension list will be worthless,
> why bother? It appears that the only reason for having a suspension list is
> because the CA is offline and want to avoid bringing the CA online to issue
> a CRL but the suspension lists needs to be issued by the CA ... (?)

You NEVER bring your CA on-line... the CSL indeed is not issued by the CA itself
as it is needed to provide a new CSL when a user asks for its suspension...
he CSL issuing should be tied to an on-line authority (as described at point
1).
 
> 3. Also why do you think that offline CAs are any different than CAs that
> only issue CRLs at fixed time intervals (i.e. every 8 hours, every hour or
> every minute). There will always be a time gap between CRL instances,
> independently if the CA is online or not, and that's were policies -of
> relaying parties, CAs, etc.- have a role.

CSLs are not CRLs... when the user asks for a suspension the status gets to
suspended in a metter of seconds (or less). This suspends the certificates
immediately and if the certificate will get revoked then track of this suspension
will be held and if some misusage of the certificate arise than you can prove
that should not be trusted as an authorized usage because it was suspended.

> If your environment needs a high level of responsiveness, a more reasonable
> approach is to solve the problems you did not state (e.g. why the CA has to
> be offline?) and bring your CA on-line using mechanisms and protocols
> appropriate for the application. Trying to develop new protocols to solve an
> apparently trivial environment/operations issue adds, as stated above,
> complexity and also interoperability issues to an already complex and less
> that interoperable environment.
> 

To me the only way of being sure about avoiding network attacks is to have the
CA disconnected from ANY network (being it internal to the organization only or not)
and this to provide an high security profile... This causes the problems related
to the suspension/revoking of certificates and time delays between the request
being received and the real revoking time of the certificate. If you are not
using this CA model than you do not suffer of such a problem (this is obvious).
As we do use this kind of structure we lack a way of providing this service...
:-D


C'you,

	Massimiliano Pala ([e-mail])
--------------ms6DF0605447C7FE6DE0D98344
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMjAzMTAyMjI3WjAjBgkqhkiG9w0BCQQxFgQUB3hlAcSSop12f/VqHGmBt3DShVsw
DQYJKoZIhvcNAQEBBQAEgYB6WHMhWAR1Jd0uGeLQzbswtC+iOb77gn00sTm/htCoRTlnbCsA
u1In1yTDwSRSrOGej+pkaWh98FXFd40dTqVkQ0BDE1WffuwlpI7vxVN6ZFRuXOccgrXGv3sn
HjhEFR/8n7qYgua48qcFWGa3pTW9FhoGbfEJanqph4juD05vNw==
--------------ms6DF0605447C7FE6DE0D98344--





Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24116 for <[e-mail]>; Thu, 3 Feb 2000 04:20:51 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id NAA07152; Thu, 3 Feb 2000 13:22:38 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 03 Feb 2000 10:51:51 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Antonio Lioy <[e-mail]>
CC: [e-mail]
Subject: Re: More on OCSP and CSL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE5E97FA70E2BA6AA670A64F7"

This is a cryptographically signed message in MIME format.

--------------msE5E97FA70E2BA6AA670A64F7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Antonio Lioy wrote:
 
> This is another view: the CSL is being used as a waiting
> list for possibly revoked certs. If it is later revoked,
> then you'll put it in the CRL, otherwise you'll remove it
> from the CSL.
> 
> But I disagree with this view: if I temporarily lost control
> of my smart-card, I can never know what has happened during
> that period of time.

Yes, but I think that if you are not sure about some misusage
of the private key, then you should request it to be revoked.

This is for two reasons: the first is about how long a CSL will
become if we keep track about every suspension of certificates
and the second is about your trusting in your key-pair.

If we keep every suspension tracked on the CSL, it can get a
very long list and it could suffer from problems related to
this aspect (distribution, definition of delta's CSL, and so
on... ). I'd like to avoid these problems as them tend to
get the CSL more complex than needed.

The second aspect is related on the fact that if you do not
trust your key for a certain period, than you should not trust
it at all because it could be open to every kind of attacks:
let's say someone discovers your password and uses it non only
when it is suspended, but he/her can get in touch with your key
during the working time when you are having a coffe-break...

If you are now trusting your key it is possible you think that
the 5 mins of a coffe break do not represent a real danger...

So my vision is: if you trust your certificate is because it has
never been in danger, if there is a possibility your certificate
(read key-pair) has been compromised (so it con be compromised
again...) either if you are not sure about it, than you should
revoke it...

So if we do not keep track on the CSLs about the suspension of
non-revoked certificates is because them are to be trusted.

> May be two years later someone claims money from me, based
> on a digital signature produced during that exact period of
> time. If you removed the entry from the CSL, you'll not be
> able to prove that it was not you that signed that document.
> 
> Do you agree?

I do understand your point of view, but how to solve problems
related to the CSL's length ?? And, moreover, how to be sure
your certificate is subject to attacks only in suspension times ??
Once a key/pair has been compromised (or possibily compromised)
it should not, to me, being trusted any more.

What do you think about this ???

C'you,

	Massimiliano Pala ([e-mail])
--------------msE5E97FA70E2BA6AA670A64F7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMjAzMDk1MTUxWjAjBgkqhkiG9w0BCQQxFgQUrVP49Z8jwsAk1Y6vY8Yya7uF8eUw
DQYJKoZIhvcNAQEBBQAEgYCyRYtq7NhJql9BcOsUHWqOnYVZVoRS+iDJ02w8XMpTASm3tRww
/j6ZqjxhVcP2pRTQl97uWaJOKCWa9YDFkMA+JCaB47FWo2VEnH8zZxTMv7L6DHywmm0S5G15
KYXV8bslQvWW098MuXmhkofLgxueCtwVpzWtvtFd+JgkV7dB2Q==
--------------msE5E97FA70E2BA6AA670A64F7--





Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20344 for <[e-mail]>; Wed, 2 Feb 2000 10:06:43 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBYG7WT>; Wed, 2 Feb 2000 19:08:25 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>, Juan Rodriguez-Torrent <[e-mail]>
Cc: [e-mail], Russ Housley <[e-mail]>
Subject: RE: OCSP and CSL
Date: Wed, 2 Feb 2000 19:07:56 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA20345

I do tend to agree to some of what Antonio is saying here:

There is a need for a historical account of the status of certificates. The
simplest way of doing this would be to allow multiple CRL entries for a
single certificate in a CRL (e.g. onHold, removeFromCrl, onHold,
keyCompromise) and indicating this extended type of CRL by some extension
(so that the consumer of the CRL understands this special use). This has to
be accompanied by an OCSP request extension that asks the responder to
evaluate the query at some certain historical point in time.

If a CA wants to do allow suspension and unsuspension is purely a policy
issue. If he does, he likely wants to keep track of this status and be able
to communicate this between relying parties in some standard way.

> 1. "revoked" means revoked, i.e. the cert is no more valid
> for any use starting from a certain date

As other people have pointed out 'onHold' (suspension) is really a type of
revocation. Whether this makes sense semantically may be a cultural thing.
For instance, in Swedish the word for revocation ("spärr") indicates that
the certificate is 'barred against use' -- which is true both for a
temporary and permanent revocation. Anyway, I don't think we can change the
words anymore (sorry).

Simon.

Simon Tardell		voice [phone], fax [phone]
iD2 Technologies		[e-mail], [e-mail]
Grand Winner of the European IT-prize 1998 http://www.it-prize.org/ 


Received: from mbox.theo.it (mbox.theo.it [193.76.75.218]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12701 for <[e-mail]>; Wed, 2 Feb 2000 06:32:56 -0800 (PST)
Received: from mirko (137.204.186.190) by mbox.theo.it with ESMTP (Eudora Internet Mail Server 2.2); Wed, 2 Feb 2000 15:39:37 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 02 Feb 2000 15:36:26 +0100
To: Ilan Shacham <[e-mail]>
From: Mirko Tedaldi <[e-mail]>
Subject: RE: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 14.30 02/02/00 +0200, Ilan Shacham wrote:

>Section 3.3 of RFC 2459 clearly states:
>         An entry may be removed from
>    the CRL after appearing on one regularly scheduled CRL issued beyond
>    the revoked certificate's validity period.
>
>If you want to validate an "old" signature, all you have to do is
>retrive the crl that was in order at the time of the signature, to
>see if the certificate was valid at the time.

About it, do you know how commercial PKI softwares work? Do they remove 
expired certificates from CRL ?

Mirko Tedaldi.



Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09475 for <[e-mail]>; Wed, 2 Feb 2000 04:33:02 -0800 (PST)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <NAA04322> (multiple receipients); Wed, 2 Feb 2000 13:35:19 +0100 (MET)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id NAA09905; Wed, 2 Feb 2000 13:34:50 +0100 (MET)
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2000 13:39:41 +0100
From: Joerg Seidel <[e-mail]>
Organization: MAZ Hamburg GmbH
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Mirko Tedaldi <[e-mail]>, [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Mirko Tedaldi schrieb:

> At 06.26 02/02/00 -0500, Irene Gassko wrote:
>
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> >This is not true. Expired certificates are deleted from CRL.
>
> If I delete expired certificates from CRLs, I could have troubles to verify
> "historical" signatures. Actually, how can I know if a digital signature
> corresponds to a certificate that was valid at the moment of signing and
> now is expired or it corresponds to a revoked certificate?
> I think this matter can happen when you verify old signatures.
>
> Is it right?

Yes, it's a problem. Even if there is a timeAttribute inside of the signature,
you can not trust this time anymore in case of an expired or revoked
certificate. You have to apply a time stamp to the signature after its
generation in order to preserve it's validity after the certificate expiration.
This is the only way to prove that the signature was made prior
revokation/expiration. Btw: This applies to the CRL-signature too.

timeproof has developed a secure hardware based Time Signature System for this
purpose. You are welcome to have a look to our web pages or visit us at CeBIT.

Best regards,
Jörg Seidel
--
timeproof Development                   phone  [phone]
Harburger Schloßstraße 6-12             fax    [phone]
D-21079 Hamburg                         mailto:[e-mail]
Germany                                 http://www.timeproof.de

      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +




Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09200 for <[e-mail]>; Wed, 2 Feb 2000 04:27:05 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <DHTL673N>; Wed, 2 Feb 2000 14:30:30 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Wed, 2 Feb 2000 14:30:20 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Antonio,

> Irene Gassko wrote:
> > 
> > At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> > 
> > This is not true. Expired certificates are deleted from CRL.
> 
> I disagree. A revoked cert MUST remain in the CRL even after
> its expiration date, because I may be willing to check if
> the cert was valid at some point in time before its natural
> expiration. That's why in a previous mail I said that that
> the size of a CRL is "monotonically increasing": you only
> add revoked certs to the CRL, and NEVER delete them, not
> even after their expiration.
> That's one of the major differences between CRL and OCSP:
> CRL are the history of all revoked certs by a certain CA,
> while OCSP offers information only for the "current" time
> slot (unless the OCSP server supports extensions to also
> look back at the history of the certs).

Section 3.3 of RFC 2459 clearly states:
	An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued beyond
   the revoked certificate's validity period.

If you want to validate an "old" signature, all you have to do is
retrive the crl that was in order at the time of the signature, to 
see if the certificate was valid at the time.

Ilan
------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864


Received: from mbox.theo.it (mbox.theo.it [193.76.75.218]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08591 for <[e-mail]>; Wed, 2 Feb 2000 04:05:48 -0800 (PST)
Received: from mirko (137.204.186.190) by mbox.theo.it with ESMTP (Eudora Internet Mail Server 2.2); Wed, 2 Feb 2000 13:00:57 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Wed, 02 Feb 2000 12:58:01 +0100
To: [e-mail]
From: Mirko Tedaldi <[e-mail]>
Subject: Re: OCSP and CSL
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06.26 02/02/00 -0500, Irene Gassko wrote:

> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
>
>This is not true. Expired certificates are deleted from CRL.

If I delete expired certificates from CRLs, I could have troubles to verify 
"historical" signatures. Actually, how can I know if a digital signature 
corresponds to a certificate that was valid at the moment of signing and 
now is expired or it corresponds to a revoked certificate?
I think this matter can happen when you verify old signatures.

Is it right?

Mirko Tedaldi.




Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07853 for <[e-mail]>; Wed, 2 Feb 2000 03:48:58 -0800 (PST)
Received: (qmail 21155 invoked from network); 2 Feb 2000 11:51:58 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 2 Feb 2000 11:51:58 -0000
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2000 12:51:06 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Irene Gassko <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAC5CC2543B9092E3A473D4DD"

This is a cryptographically signed message in MIME format.

--------------msAC5CC2543B9092E3A473D4DD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Irene Gassko wrote:
> 
> At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
> 
> This is not true. Expired certificates are deleted from CRL.

I disagree. A revoked cert MUST remain in the CRL even after
its expiration date, because I may be willing to check if
the cert was valid at some point in time before its natural
expiration. That's why in a previous mail I said that that
the size of a CRL is "monotonically increasing": you only
add revoked certs to the CRL, and NEVER delete them, not
even after their expiration.
That's one of the major differences between CRL and OCSP:
CRL are the history of all revoked certs by a certain CA,
while OCSP offers information only for the "current" time
slot (unless the OCSP server supports extensions to also
look back at the history of the certs).

> >Given these considerations, I'm here advocating the
> >technical need for some kind of "cert history". For example,
> >we could extend CRLs (to become a CRSL) to allow each entry
> >to represent a certificate that has been revoked or
> >suspended at least once (so, no need to insert good
> >certificates that expire for natural reasons) and to append
> >a list of suspension periods.
> >For example:
> >   CERT #123
> >   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
> >09:00 GMT+1
> >   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
> >09:00 GMT+1
> >   revoked on 02-feb-2000 09:02 GMT+1
> >That would allow anybody to locally store data and be able
> >to always verify (even offline or in the future) the
> >validity of the certs issued by a certain CA.
>
> This could be useful for archiving purposes.

That's exactly one of my points.

Cheers,

Antonio Lioy
--------------msAC5CC2543B9092E3A473D4DD
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMjAyMTE1MTA2WjAjBgkqhkiG9w0BCQQxFgQUlDVcCPd3JKlXO1NQhszqui2N
2DowDQYJKoZIhvcNAQEBBQAEgYBlsxp8zC5ElhTYhyf/mt4iJKpOaUbLO9nduiHqpnNhPASt
Acyun61PsJtFMtujoul4AR+HhgUQSsdY3XiHgVAv5nq8DHGdLmcpE+PhRUa1mfWQnFBmwrGf
PBCpkI38p5biSnyXGJZINK3Hn/jQ6mZy7/W5GbI7jDm6J5oylvGi7A==
--------------msAC5CC2543B9092E3A473D4DD--



Received: from auemail2.firewall.lucent.com ([192.11.223.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06649 for <[e-mail]>; Wed, 2 Feb 2000 03:22:57 -0800 (PST)
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA05853 for <[e-mail]>; Wed, 2 Feb 2000 06:25:16 -0500 (EST)
Received: from anuxc.mv.lucent.com (h135-13-160-12.lucent.com [135.13.160.12]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA05846; Wed, 2 Feb 2000 06:25:16 -0500 (EST)
Received: from irg-pc by anuxc.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id GAA10124; Wed, 2 Feb 2000 06:23:29 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 02 Feb 2000 06:26:57 -0500
To: Antonio Lioy <[e-mail]>
From: Irene Gassko <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
>Juan Rodriguez-Torrent wrote:
>[snip]
>I'm mildly unsatisfied of the recent discussion over this
>list. It appears that everybody is against certificate
>suspension, given its associated cost. I think that, when
>speaking technically, we should abide from the associated
>costs of operation, because those costs are quite sensitive
>to the perceived needs from the users (otherwise we would
>never define or adopt strong security measures because they
>are surely too expensive :-)
>Moreover, some mails suggest to use CRL with the OnHold
>reason for suspension, and later remove the certificate if
>it is not actually revoked. What??? I have some really bad
>feeling about this solution because my understanding is:
>1. "revoked" means revoked, i.e. the cert is no more valid
>for any use starting from a certain date

If we look for a real world analogy here, I would expect that it
would be instructive to see how credit card companies handle it.
Most will close your account forever, but when I called AMEX
and asked them to close my account, they told me that within
a year I could reopen it if I changed my mind. Hence this is at
least debatable.

>2. once a cert is inserted into a CRL, it can *never* be
>deleted from it 

This is not true. Expired certificates are deleted from CRL.

[snip]
>
>Given these considerations, I'm here advocating the
>technical need for some kind of "cert history". For example,
>we could extend CRLs (to become a CRSL) to allow each entry
>to represent a certificate that has been revoked or
>suspended at least once (so, no need to insert good
>certificates that expire for natural reasons) and to append
>a list of suspension periods.
>For example:
>   CERT #123
>   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
>09:00 GMT+1
>   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
>09:00 GMT+1
>   revoked on 02-feb-2000 09:02 GMT+1
>That would allow anybody to locally store data and be able
>to always verify (even offline or in the future) the
>validity of the certs issued by a certain CA.
>
This could be useful for archiving purposes.

Irene

>Thanks for your attention.
>
>Antonio Lioy
I
----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	[phone]
Room 30-2-A31			 e-mail: 	[e-mail]
N. Andover, MA 01845		 fax: 	[phone]


Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA03465 for <[e-mail]>; Wed, 2 Feb 2000 02:46:42 -0800 (PST)
Received: (qmail 6245 invoked from network); 2 Feb 2000 10:49:31 -0000
Received: from unknown.datafellows.com (HELO dffw1) (194.252.6.33) by dfmail.datafellows.com with SMTP; 2 Feb 2000 10:49:31 -0000
Received: (qmail 8038 invoked from network); 2 Feb 2000 10:43:43 -0000
Received: from dfp100.datafellows.com (HELO F-Secure.com) (194.197.29.149) by dfintra.datafellows.com with SMTP; 2 Feb 2000 10:43:43 -0000
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2000 12:45:36 +0200
From: Camillo =?iso-8859-1?Q?S=E4rs?= <[e-mail]>
Organization: F-Secure Corporation (formerly Data Fellows Corporation)
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: sv-FI,sv,en,fi,fr
MIME-Version: 1.0
To: Antonio Lioy <[e-mail]>
CC: Juan Rodriguez-Torrent <[e-mail]>, [e-mail], Russ Housley <[e-mail]>
Subject: Re: OCSP and CSL
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Antonio Lioy wrote:
> One of them asked us for suspending the cert validity associated to a 
> signing engine that cannot be easily removed from the host, because that
> engine should operate only during the physical presence of
> the person legally in charge of the signature.

In that case you are confusing authentication and authorization.  I suggest
considering authorization certificates for this.  They can be very
short-lived and are easy to revoke.  Of course, they are also at least
somewhat controversial at this point.

Suspending the binding between a name and a key is unintuitive, and really
doesn't make sense.  I think you are trying to impose unwanted semantics on
identity certificates!

Regards,
Camillo Särs
-- 
Camillo Särs <[e-mail]>       http://www.iki.fi/ged/
Researcher, Crypto Research                    http://www.F-Secure.com/
F-Secure Corporation   (formerly Data Fellows Corporation)
   F-Secure products: Integrated Solutions for Enterprise Security


Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA29050 for <[e-mail]>; Wed, 2 Feb 2000 00:44:21 -0800 (PST)
Received: (qmail 21062 invoked from network); 2 Feb 2000 08:47:12 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 2 Feb 2000 08:47:12 -0000
Message-ID: <[e-mail]>
Date: Wed, 02 Feb 2000 09:46:27 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juan Rodriguez-Torrent <[e-mail]>
CC: [e-mail], Russ Housley <[e-mail]>
Subject: Re: OCSP and CSL
References: <[e-mail]> <007601bf6c78$e0c2c780$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDFE8DE75D5F1236F89C5299F"

This is a cryptographically signed message in MIME format.

--------------msDFE8DE75D5F1236F89C5299F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juan Rodriguez-Torrent wrote:
> 
> Russ, I cannot agree more. I'm just trying to figure out if these are real
> customer requirements or some folks in a glass house tinkering with
> possibilities.

Sorry but I'm quite serious. Although I'm a university
professor, I'm also a practical engineer and I'm not sitting
in a glass house tinkering with possibilities. We are
actively developing a PKI here in Italy and we have
requirements from partners. One of them asked us for
suspending the cert validity associated to a signing engine
that cannot be easily removed from the host, because that
engine should operate only during the physical presence of
the person legally in charge of the signature.
I know that the easiest solution would be to switch off the
machine (and to physically secure it so that nobody can
switch it on) but that cannot be done because the machine
offers other services too. In turn, you could suggest to
duplicate the machine. But I was wondering if there was
nothing simpler like just suspending the certificate. If it
turns out that suspension is a nightmare, fine: I'll suggest
to duplicate the machine, switch it off, and lock it.
But wait a moment: the italian law requires every legally
binding CA:
- to mantain a "signed list of revoked certificates" (they
do use the world CRL and refer to the ISO standard)
- to mantain a "signed list of suspended certificates" (they
do use the world CSL, but they don't define it)
- to permit inquiries over the net to those lists (they
don'use the world OCSP or CRL/CSL distribution over HTTP or
FTP)
so there are lots of CAs here in Italy that are inventing
their own format for CSL.
I just wanted to investigate if teh it was given enough
thoughts to certificate suspension.

I'm mildly unsatisfied of the recent discussion over this
list. It appears that everybody is against certificate
suspension, given its associated cost. I think that, when
speaking technically, we should abide from the associated
costs of operation, because those costs are quite sensitive
to the perceived needs from the users (otherwise we would
never define or adopt strong security measures because they
are surely too expensive :-)
Moreover, some mails suggest to use CRL with the OnHold
reason for suspension, and later remove the certificate if
it is not actually revoked. What??? I have some really bad
feeling about this solution because my understanding is:
1. "revoked" means revoked, i.e. the cert is no more valid
for any use starting from a certain date
2. once a cert is inserted into a CRL, it can *never* be
deleted from it 
If these principles are not true, then please change the
name of CRL to something else, as it doesn't store revoked
certs but temporarly invalid certs. There is nothing more
bad about a standard than using words in a counterintuitive
way.
I ASK FOR A FINAL AUTHORITATIVE WORD HERE: POINT 1 AND 2 ARE
TRUE OR NOT?

Someone advocates more extended usage of OCSP. Apart from
the same terminology issue (the "revoked" status that may be
returned from OCSP doesn't actually mean revoked, hey we are
all joking! if the secondary code is OnHold, check later and
may be it was actually revoked or not) I dislike this
approach because it applies only to on-line transactions: if
I receive a transaction request, then I check the status of
the requesting cert with OCSP and I store the signed answer
as a proof. But there are organizations that want to be
*autonomously* able to perform checks about cert validity at
a certain point in time. Currently, they periodically
request CRLs from their trusted CAs and store them locally.
So even in the case the CA vanishes, they have their own
proof.

Given these considerations, I'm here advocating the
technical need for some kind of "cert history". For example,
we could extend CRLs (to become a CRSL) to allow each entry
to represent a certificate that has been revoked or
suspended at least once (so, no need to insert good
certificates that expire for natural reasons) and to append
a list of suspension periods.
For example:
   CERT #123
   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
09:00 GMT+1
   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
09:00 GMT+1
   revoked on 02-feb-2000 09:02 GMT+1
That would allow anybody to locally store data and be able
to always verify (even offline or in the future) the
validity of the certs issued by a certain CA.

Thanks for your attention.

Antonio Lioy
--------------msDFE8DE75D5F1236F89C5299F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMjAyMDg0NjI3WjAjBgkqhkiG9w0BCQQxFgQUofY9WMpVF/QPnU9QXL+gyJnt
6j0wDQYJKoZIhvcNAQEBBQAEgYBi+imtDkMBZsZFejN2gm2MmJc0aECqg31CKx7Cu32I36Rv
3qpw5oGLZ02yWdTgbkjhWYK3Kqqie0qOZH9bKG3K2yMhL4x5RphVZ5aeOA7Ex6Tsjf36GJMb
ESxlRItBtxEpGd5VfCSra+I/owBNUIO/kC3Wj4z3TStcBF3fAtZQAQ==
--------------msDFE8DE75D5F1236F89C5299F--



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08386 for <[e-mail]>; Tue, 1 Feb 2000 09:44:22 -0800 (PST)
Received: from npwork2 (e1h2p23.scotland.net [148.176.234.24]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id PAA19442 for <[e-mail]>; Tue, 1 Feb 2000 15:43:17 GMT
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Subject: Request for Information to European Standard on Policies for Certification Service Providers
Date: Tue, 1 Feb 2000 15:50:46 -0000
Message-ID: <001401bf6ccc$1ae581c0$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01BF6CCC.1AE581C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BF6CCC.1AE581C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

ETSI (European Telecommunications Standards Institute), as part a general
initiative on standards for electronic signatures, is working on Policies
for Certification Service Providers (CSPs).

It is requested that organisation with interests in this area provides views
on requirements and any existing documentation that may be revelant.  The
attached document provides further details of the Request for Information
and the scope of this activity.

If your organisation has interests in this area can you consider responding
to this RFI.

Thanks

Nick Pope

------=_NextPart_000_0015_01BF6CCC.1AE581C0
Content-Type: application/msword;
	name="ETSI-RFI-fin-25jan00.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ETSI-RFI-fin-25jan00.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA
EAAAQQAAAAEAAAD+////AAAAAD4AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJCAAAABK/AAAAAAAAEAAAAAAABAAA5jAAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAIUIAABZBAQAWQQEA3ywAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAABICAAAAAAAAEgIAABIC
AAAAAAAAEgIAAAAAAAASAgAAAAAAABICAAAAAAAAEgIAABQAAAAAAAAAAAAAAH4CAAAAAAAAfgIA
AAAAAAB+AgAAAAAAAH4CAAA4AAAAtgIAAAwAAADCAgAAJAAAAH4CAAAAAAAACBQAALYAAAACAwAA
AAAAAAIDAAAAAAAAAgMAAAAAAAACAwAAAAAAAAIDAAAAAAAAAgMAAAAAAAACAwAAAAAAAAIDAAAA
AAAAzRMAAAIAAADPEwAAAAAAAM8TAAAAAAAAzxMAAAAAAADPEwAAAAAAAM8TAAAAAAAAzxMAACQA
AAC+FAAA9AEAALIWAACMAAAA8xMAABUAAAAAAAAAAAAAAAAAAAAAAAAAEgIAAAAAAAACAwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAACAwAAAAAAAAIDAAAAAAAAAgMAAAAAAAACAwAAAAAAAPMTAAAAAAAA
PgUAAAAAAAASAgAAAAAAABICAAAAAAAAAgMAAAAAAAAAAAAAAAAAAAIDAAAAAAAAAgMAAAAAAAA+
BQAAAAAAAD4FAAAAAAAAPgUAAAAAAAACAwAAMAEAABICAAAAAAAAAgMAAAAAAAASAgAAAAAAAAID
AAAAAAAAzRMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgIAACwAAABSAgAALAAAABICAAAAAAAAEgIA
AAAAAAASAgAAAAAAABICAAAAAAAAAgMAAAAAAADNEwAAAAAAAD4FAAAyBQAAPgUAAAAAAABwCgAA
agIAAKQRAAD3AQAAEgIAAAAAAAASAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzRMAAAAAAAACAwAAAAAAAOYCAAAcAAAAMFabBSho
vwF+AgAAAAAAAH4CAAAAAAAAMgQAAAwBAACbEwAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARVRT
SSBFU0kgliBFRVNTSSBXb3JrIFByb2dyYW1tZQ1Qb2xpY2llcyBmb3IgQ1NQcw0gUmVxdWVzdCBm
b3IgSW5mb3JtYXRpb24NMjUgSmFuLiAyMDAwDVRoZSBFVFNJIFRDU0VDIEVTSSB3b3JraW5nIGdy
b3VwIChFdXJvcGVhbiBUZWxlY29tbXVuaWNhdGlvbnMgU3RhbmRhcmRzIEluc3RpdHV0ZSwgVGVj
aG5pY2FsIENvbW1pdHRlZSBvbiBTZWN1cml0eSwgRWxlY3Ryb25pYyBTaWduYXR1cmUgYW5kIElu
ZnJhc3RydWN0dXJlIHdvcmtpbmcgZ3JvdXApIGlzIHdvcmtpbmcgb24gYSBzdGFuZGFyZCBhZGRy
ZXNzaW5nIGZ1bmN0aW9uYWwgYW5kIHF1YWxpdHkgcmVxdWlyZW1lbnRzIGZvciBDZXJ0aWZpY2F0
aW9uIFNlcnZpY2UgUHJvdmlkZXJzIChDU1BzKS4gIFRoaXMgd29yayBpdGVtIGlzIGJlaW5nIGNh
cnJpZWQgb3V0IGluIGNsb3NlIGNvbGxhYm9yYXRpb24gd2l0aCBDRU4vSVNTUyB3aXRoaW4gdGhl
IG92ZXJhbGwgZnJhbWV3b3JrIG9mIHRoZSBFdXJvcGVhbiBFbGVjdHJvbmljIFNpZ25hdHVyZSBT
dGFuZGFyZGl6YXRpb24gSW5pdGlhdGl2ZSAoRUVTU0kpLg1UaGUgaW5pdGlhbCBmb2N1cyBvZiB0
aGlzIHN0YW5kYXJkIGlzIHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cyBvZiBDU1BzIGlzc3Vp
bmcgcXVhbGlmaWVkIGNlcnRpZmljYXRlcyBhcyBpZGVudGlmaWVkIGluIEFubmV4IElJIG9mIHRo
ZSBFdXJvcGVhbiBEaXJlY3RpdmUgb24gRWxlY3Ryb25pYyBTaWduYXR1cmVzIGFzIHRoaXMgcHJv
dmlkZXMgYSBjb21tb24gZGlyZWN0aW9uIGZvciBzdGFuZGFyZGl6YXRpb24gd2hpY2ggaGFzIGJl
ZW4gYWdyZWVkIGFjcm9zcyB0aGUgRXVyb3BlYW4gbmF0aW9ucy4gIFRoaXMgd29yayBpdGVtIHdp
bGwgYWRkcmVzcyByZXF1aXJlbWVudHMgb24gdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBvZiBz
dWNoIGEgQ1NQIGluIHBhcnRpY3VsYXIgUmVnaXN0cmF0aW9uIEF1dGhvcml0eSwgQ2VydGlmaWNh
dGUgUmVwb3NpdG9yeSBhbmQgdGhlIFJldm9jYXRpb24gU2VydmljZSAoZS5nLiB1c2luZyBjZXJ0
aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3Qgb3IgYW4gb24tbGluZSBjZXJ0aWZpY2F0ZSBzdGF0dXMg
cHJvdG9jb2wpLg1JdCBpcyByZWNvZ25pc2VkLCBob3dldmVyLCB0aGF0IEFubmV4IElJIG1heSBu
b3QgbWF0Y2ggdGhlIHJhbmdlIG9mIHJlcXVpcmVtZW50cyBmb3IgQ1NQIGZ1bmN0aW9uYWwgYW5k
IHF1YWxpdHkgc3RhbmRhcmRpemF0aW9uLiAgUmVxdWlyZW1lbnRzIG9mIHdpZGUgbWFya2V0IHNl
Z21lbnRzLCBpZiBkaWZmZXJlbnQgZnJvbSB0aG9zZSBvZiBhbm5leCBJSSwgYXJlIHRvIGJlIGNv
dmVyZWQgYnkgdGhlIHN0YW5kYXJkIGFzIHdlbGwuICBUaGUgb3ZlcmFsbCBvYmplY3RpdmUgb2Yg
dGhpcyB3b3JrIHByb2dyYW1tZSBpcyB0byBkZWZpbmUgc3RhbmRhcmRzIGZvciB0aGUgcmFuZ2Ug
b2YgY2xhc3NlcyBvZiBlbGVjdHJvbmljIHNpZ25hdHVyZSB0aGF0IHdpbGwgaGF2ZSBsZWdhbCBy
ZWNvZ25pdGlvbiBhY3Jvc3MgRXVyb3BlIGFuZCB0byBkZWZpbmUgcmVxdWlyZW1lbnRzIGZvciBD
U1BzIGlzc3Vpbmcgb3RoZXIgZm9ybXMgb2YgY2VydGlmaWNhdGUgKGUuZy4gY3Jvc3MgY2VydGlm
aWNhdGVzKSBhbmQgc3VwcG9ydGluZyBvdGhlciB0eXBlcyBvZiBDU1Agc2VydmljZS4gDUludGVy
bmF0aW9uYWwsIEV1cm9wZWFuIGFuZCBuYXRpb25hbCBjb21tdW5pdGllcywgYXV0aG9yaXRpZXMs
IGFzc29jaWF0aW9ucywgc3RhbmRhcmRpemF0aW9uIGJvZGllcywgdmVuZG9ycywgc2VydmljZSBw
cm92aWRlcnMsIHVzZXJzIGFyZSByZXF1ZXN0ZWQgdG8gcHJvdmlkZSBhbnkgaW5mb3JtYXRpb24g
dGhhdCBpcyByZWxldmFudCB0byB0aGlzIGFjdGl2aXR5IHRvIHRoZSBjaGFpcm1hbiBvZiBFVFNJ
IEVTSSBhbmQgdGhlIHRhc2sgbGVhZGVyIGZvciB0aGlzIGFyZWEgb2Ygc3RhbmRhcmRpemF0aW9u
IChzZWUgYmVsb3cpLiAgSW4gcGFydGljdWxhciwgRVRTSSBFU0kgcmVxdWVzdHMgaW5wdXQgb246
DVZpZXdzIG9uIG1pbmltdW0gZXNzZW50aWFsIHJlcXVpcmVtZW50cywgdmFyaWFudHMgLyByZWZp
bmVtZW50cyB0byB0aGUgRGlyZWN0aXZlLCBuZWVkcyBmb3IgYWx0ZXJuYXRpdmUgbGV2ZWxzIG9m
IHRydXN0IGFuZCBzdXBwb3J0IGZvciBhbHRlcm5hdGl2ZSBmb3JtcyBvZiBjZXJ0aWZpY2F0ZSAo
ZS5nLiBhdHRyaWJ1dGUgY2VydGlmaWNhdGUpDVJlbGV2YW50IGRvY3VtZW50cyBhbmQgc3BlY2lm
aWNhdGlvbnMgKGRyYWZ0IG9yIGFwcHJvdmVkKSCWIHByZWZlcmFibHkgaW4gRW5nbGlzaA1FdmVu
IGlmIHlvdXIgb3JnYW5pemF0aW9uIGhhcyBubyBzcGVjaWZpYyBpbnB1dCB0byBtYWtlLCBpbmRp
Y2F0aW9ucyBvZiBpbnRlcmVzdCBpbiB0aGlzIGFjdGl2aXR5IHdvdWxkIGJlIHdlbGNvbWVkLiAg
V2UgY2FuIHRoZW4ga2VlcCB5b3UgaW5mb3JtZWQgb2YgdGhlIGF2YWlsYWJpbGl0eSBvZiBkcmFm
dHMgZm9yIGNvbW1lbnQuDVJlc3BvbnNlIGlzIHJlcXVlc3RlZCBieSBlbmQgRmVicnVhcnkgMjAw
MC4gIEhvd2V2ZXIsIGlmIG1lZXRpbmcgc2NoZWR1bGVzIGRvIG5vdCBtYWtlIHRoaXMgcG9zc2li
bGUsIGlucHV0IGF0IHRoZSBlYXJsaWVzdCBjb252ZW5pZW5jZSBkYXRlIHdvdWxkIGJlIHdlbGNv
bWVkLg1JdCBpcyBwbGFubmVkIHRvIHByb2R1Y2UgYSBmaXJzdCB3b3JraW5nIGRyYWZ0IGZvciBn
ZW5lcmFsIHJldmlldyBieSAzcmQgcXVhcnRlciBvZiB0aGlzIHllYXIuDUFuIG91dGxpbmUgb2Yg
dGhlIHNjb3BlIG9mIHRoaXMgd29yayBpdGVtIGlzIGFwcGVuZGVkLiAgRnVydGhlciBkZXRhaWxz
LCBkb2N1bWVudHMsIGFuZCBlLW1haWwgbGlzdCByZWdpc3RyYXRpb24gb24gdGhpcyBhbmQgb3Ro
ZXIgYWN0aXZpdGllcyBvZiBFVFNJIG9uIGVsZWN0cm9uaWMgc2lnbmF0dXJlIHN0YW5kYXJkaXph
dGlvbiBtYXkgYmUgZm91bmQgb246CyAJaHR0cDovL3d3dy5ldHNpLm9yZy9zZWMvZWwtc2lnbi5o
dG0NUGxlYXNlIHNlbmQgcmVzcG9uc2VzIHRvOg1HeW9yZ3kgRW5kZXJzegtDaGFpciBFVFNJIEVT
SSBXb3JraW5nIEdyb3VwC0d5b3JneS5HLkVuZGVyc3pAdGVsaWEuc2UNYW5kDUVUU0kgdGFzayBs
ZWFkZXIgliBQb2xpY2llcyBmb3IgQ1NQcwtOaWNrIFBvcGULcG9wZUBzZWNzdGFuLmNvbQ0MRVRT
SSBFU0kgliBFRVNTSSBXb3JrIFByb2dyYW1tZQ1Qb2xpY2llcyBmb3IgQ1NQcw0gU2NvcGUgU3Rh
dGVtZW50DU9iamVjdGl2ZQ1UaGUgYWltIG9mIHRoaXMgd29yayBhcmVhIGlzIHRvIHNwZWNpZnkg
cG9saWN5IHJlcXVpcmVtZW50cyBvbiB0aGUgb3BlcmF0aW9uIGFuZCBtYW5hZ2VtZW50IG9mIENT
UHMgKENlcnRpZmljYXRpb24gU2VydmljZSBQcm92aWRlcnMpIHRvIHByb3ZpZGUgcmVjb2duaXNl
ZCBsZXZlbHMgb2YgdHJ1c3QuIFRoZSByZXF1aXJlbWVudHMgc2hvdWxkIGNvdmVyIGNvbXBvbmVu
dHMgKENlcnRpZmljYXRpb24gQXV0aG9yaXR5LCBSZWdpc3RyYXRpb24gQXV0aG9yaXR5LCBEaXJl
Y3RvcnksIGV0Yykgb2YgdGhlIENTUCBpbmZyYXN0cnVjdHVyZSB0byB0aGUgZXh0ZW50IGFuZCBk
ZXRhaWwgbGV2ZWwsIHdoaWNoIGlzIHN1ZmZpY2llbnQgdG8gZXN0YWJsaXNoIHRydXN0IGluIHRo
ZSBzZXJ2aWNlcyBhcyByZXF1aXJlZCBhbmQgdG8gZ2l2ZSB0aGUgbmVjZXNzYXJ5IGd1aWRhbmNl
IGZvciBwcmFjdGljYWwgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbi4NU2NvcGUgLSBGaXJz
dCBQaGFzZSANVGhlIGFpbSBvZiB0aGUgZmlyc3QgcGhhc2UgaXMgdG8gc3BlY2lmeSBwb2xpY3kg
cmVxdWlyZW1lbnRzIG9uIHRoZSBvcGVyYXRpb24gYW5kIG1hbmFnZW1lbnQgb2YgQ1NQcyAoQ2Vy
dGlmaWNhdGlvbiBTZXJ2aWNlIFByb3ZpZGVycykgaXNzdWluZyBRdWFsaWZpZWQgQ2VydGlmaWNh
dGVzIGluIGFjY29yZGFuY2Ugd2l0aCBBbm5leCBJSSBvZiB0aGUgRXVyb3BlYW4gZGlyZWN0aXZl
IG9uIGVsZWN0cm9uaWMgc2lnbmF0dXJlcy4gICBJdCBpcyB0byBwcm92aWRlIHRoZSBsZXZlbCBv
ZiBhc3N1cmFuY2UgZ2VuZXJhbGx5IGNvbnNpZGVyZWQgbmVjZXNzYXJ5IHRvIG1lZXQgdGhlIHJl
cXVpcmVtZW50cyBvZiBBbm5leCBJSSBhbmQgZm9yIGEgY29tbWVyY2lhbCBzZXJ2aWNlIG9mZmVy
ZWQgYWNyb3NzIEV1cm9wZSBvbiBvcGVuIG5ldHdvcmtzIHN1Y2ggYXMgdGhlIEludGVybmV0IHRh
a2luZyBvbiB0aGUgbGlhYmlsaXRpZXMgcmVxdWlyZWQgdW5kZXIgYXJ0aWNsZSA2IG9mIHRoZSBk
aXJlY3RpdmUuICANVGhlIGZpcnN0IHBoYXNlIHdpbGwgYWxzbyBzdGFydCB0aGUgcHJvY2VzcyB0
byBpZGVudGlmeSB0aGUgd2lkZXIgbWFya2V0IHJlcXVpcmVtZW50cyBmb3Igc3RhbmRhcmRpemF0
aW9uIG1lZXRpbmcgdGhlIGdlbmVyYWwgb2JqZWN0aXZlcyBvZiB0aGlzIGFjdGl2aXR5Lg1Jbml0
aWFsIFJlZmVyZW5jZXMNVGhlIHN0YW5kYXJkIHdpbGwgYmUgYmFzZWQgb24gZXhpc3Rpbmcgc3Rh
bmRhcmRzIGFuZCBwdWJsaWNseSBhdmFpbGFibGUgc3BlY2lmaWNhdGlvbnMuICBEb2N1bWVudHMg
YmVpbmcgY29uc2lkZXJlZCBpbmNsdWRlOg1JRVRGIFJGQyAyNTI3IEludGVybmV0IFguNTA5IFB1
YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgQ2VydGlmaWNhdGUgUG9saWN5IGFuZCBDZXJ0aWZpY2F0
aW9uIFByYWN0aWNlcyBGcmFtZXdvcmsNQU5TSSBYOS43OSBGaW5hbmNpYWwgU2VydmljZXMgliBQ
S0kgliBQcmFjdGljZXMgYW5kIFBvbGljeSBmcmFtZXdvcmsNQlMgNzc5OSBDb2RlIG9mIFByYWN0
aWNlIGZvciBJbmZvcm1hdGlvbiBTZWN1cml0eSBNYW5hZ2VtZW50DUlTTyAxNTc4MiBCYW5raW5n
IC0tIENlcnRpZmljYXRlIE1hbmFnZW1lbnQNSVNPIFRSIDEzMzM1IEd1aWRlbGluZXMgZm9yIHRo
ZSBNYW5hZ2VtZW50IG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgU2VjdXJpdHktR01JVFMNSVNP
IFBEVFIgIDE0NTE2IEd1aWRlbGluZXMgb24gdGhlIHVzZSBhbmQgbWFuYWdlbWVudCBvZiAgVHJ1
c3RlZCBUaGlyZCBQYXJ0eSBzZXJ2aWNlcw1JU08gMTU0MDggRXZhbHVhdGlvbiBjcml0ZXJpYSBm
b3IgSVQgc2VjdXJpdHkNSUNDIEdVSURFQywgRS10ZXJtcw1OSVNUIFBLSSBQcm9qZWN0IFRlYW06
IFNlY3VyaXR5IFJlcXVpcmVtZW50cyBmb3IgQ2VydGlmaWNhdGUgSXNzdWluZyBhbmQgTWFuYWdl
bWVudCBDb21wb25lbnRzIA1UaGUgYWJvdmUgdGl0bGVzIHNob3VsZCBiZSBjb25zaWRlcmVkIGFz
IHNhbXBsZXMgZnJvbSBhIHdpZGVyIHNlbGVjdGlvbiBvZiByZWxldmFudCBkb2N1bWVudHMsIG5v
dCBhcyBhbiBleGhhdXN0aW5nIGxpc3Qgb2YgcmVmZXJlbmNlcy4gSW4gYWRkaXRpb24sIHRoZXJl
IGV4aXN0IGEgbnVtYmVyIG9mIHNwZWNpZmljYXRpb25zIGZvciBDU1BzIGluIHRoZSBwdWJsaWMs
IGdvdmVybm1lbnQgYW5kIGNvbW1lcmNpYWwgZG9tYWluIGluIGRpZmZlcmVudCBjb3VudHJpZXMg
dG8gYmUgY29uc2lkZXJlZC4gDUN1cnJlbnQgU3VnZ2VzdGlvbnMNQXMgYSBmaXJzdCBzdGVwIGEg
ZnJhbWV3b3JrIGZvciB0aGUgc3RhbmRhcmQgaXMgdG8gYmUgZGV2ZWxvcGVkIHdoaWNoIHdpbGwg
c2VydmUgYXMgdGhlIGJhc2lzIGZvciB0aGUgc3Vic2VxdWVudCBkcmFmdCBzdGFuZGFyZC4gIFRo
aXMgbWF5IGluY2x1ZGU6DWEgY29tbW9uIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNvbmNlcHRzOw1j
bGFyaWZpY2F0aW9uIG9mIHRoZSByb2xlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGluIHJlbGF0aW9u
IHRvIHRoZSBDU1AsIGFjY2VkaXRvcnMvYXVkaXRvcnMsIHRoZSBzaWduZXIgLyByZWx5aW5nIHBh
cnR5LCBjZXJ0aWZpY2F0ZSBmb3JtYXQ7DXRoZSByb2xlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIHdp
dGhpbiBhIHdpZGVyIGJ1c2luZXNzIJNtb2RlbJQ7DSB0aGUgc3ViLXRvcGljcyB0byBiZSBpbmNs
dWRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NSXQgaXMgaW5pdGlhbGx5IHN1Z2dlc3RlZCB0aGF0
IHRoZSBwb2xpY3kgcmVxdWlyZW1lbnRzIHNwZWNpZmllZCBpbiB0aGUgc3RhbmRhcmQgaW5jbHVk
ZToNQ2VydGlmaWNhdGUgcG9saWN5IHNwZWNpZmljYXRpb24gYmFzZWQgb24gdGhlIGZyYW1ld29y
ayBmb3IgQ2VydGlmaWNhdGUgUG9saWNpZXMgZGVmaW5lZCBpbiBSRkMgMjUyNyBhZGFwdGVkIGFz
IG5lY2Vzc2FyeSB0byBtZWV0IHRoZSBvYmplY3RpdmUgaWRlbnRpZmllZCBhYm92ZS4gDVJlcXVp
cmVtZW50IG9uIHRoZSBmb3JtIG9mIENlcnRpZmljYXRpb24gUHJhY3RpY2UgU3RhdGVtZW50cywg
aWYgcHJvZHVjZWQgYnkgdGhlIENTUC4NQSBtb2RlbCBQS0kgZGlzY2xvc3VyZSBzdGF0ZW1lbnQg
KFBEUykgZm9yIGRpc2Nsb3N1cmUgb2YgdGhlIG1vc3QgY3JpdGljYWwgYXNwZWN0cyBvZiB0aGUg
ZGVmaW5lZCBwb2xpY3kgYW5kIHRoZSBDUFMgb2YgYSBDU1AgaXNzdWluZyBxdWFsaWZpZWQgY2Vy
dGlmaWNhdGVzLiBUaGUgUERTIGlzIGludGVuZGVkIHRvIGJlIGFuIGluc3RydW1lbnQgc3VpdGFi
bGUgZm9yIGNvbW11bmljYXRpb24gb2YgY3JpdGljYWwgYXNwZWN0cyB0byBjb25zdW1lcnMsIGFu
ZCBtYXkgYmUgYWR2YW5jZWQgYnkgdGhlIENTUCBhcyBhbiBFVEVSTSBpbiB0aGUgSW50ZXJuYXRp
b25hbCBDaGFtYmVyIG9mIENvbW1lcmNlIEVURVJNUyByZXBvc2l0b3J5LiANRGVmaW5lZCBzdGF0
ZW1lbnRzIGZvciBpbmNsdXNpb24gaW4gcXVhbGlmaWVkIGNlcnRpZmljYXRlcy4gT25lIHN0YXRl
bWVudCBzaGFsbCBkZWZpbmUgdGhhdCBhIGNlcnRpZmljYXRlIGlzIGludGVuZGVkIGJ5IHRoZSBp
c3N1ZXIgdG8gc2VydmUgYXMgYSBxdWFsaWZpZWQgY2VydGlmaWNhdGUgYWNjb3JkaW5nIHRvIHRo
ZSBEaXJlY3RpdmUgYW5uZXggSSBhbmQgSUkuIE90aGVyIGRlZmluZWQgc3RhdGVtZW50cyBtYXkg
YmUgcmVsYXRlZCB0byBzcGVjaWZpYyBwb2xpY3kgYXNwZWN0cyBzdWNoIGFzIHJlbGlhbmNlIGxp
bWl0cyBhbmQgY29uZm9ybWFuY2UgdG8gc29tZSBwYXJ0aWN1bGFyIGFzc3VyYW5jZSBsZXZlbC4N
U29tZSBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIGluY2x1c2lvbiBvZiBpbmZvcm1hdGlvbiBpbiB0
aGUgY2VydGlmaWNhdGUgbWF5IGJlIGFkZHJlc3NlZCBieSBpbmNvcnBvcmF0aW9uIGJ5IHJlZmVy
ZW5jZSB0byBhIFBLSSBkaXNjbG9zdXJlIHN0YXRlbWVudC4NUmVxdWlyZW1lbnRzIGZvciByZWdp
c3RyYXRpb24gYW5kIGtleSBnZW5lcmF0aW9uIGNvdmVyaW5nIGEgcmFuZ2Ugb2YgYWx0ZXJuYXRp
dmUgYXBwcm9hY2hlczsgdGhpcyB3aWxsIGluY2x1ZGUgcmVxdWlyZW1lbnRzIGZvciBwcml2YXRl
IGtleSBnZW5lcmF0aW9uIGFuZCBkaXN0cmlidXRpb24gb24gk3NlY3VyZZQgbWVkaWEsIGUuZy4g
c21hcnQgY2FyZHMgYW5kIFNJTXMuDVJlcXVpcmVtZW50cyBvbiBjZXJ0aWZpY2F0ZSBwdWJsaWNh
dGlvbiBhbmQgZGlzdHJpYnV0aW9uIG9uIHZhcmlvdXMgc29ydHMgb2YgbWVkaWEuDVJlcXVpcmVt
ZW50cyBvbiBzZWN1cml0eSBtYW5hZ2VtZW50IHByYWN0aWNlcyBvZiB0aGUgQ1NQLg1HZW5lcmFs
IHJlcXVpcmVtZW50cyBvbiB0aGUgdHJ1c3RlZCBjb21wdXRlciBzeXN0ZW0gYW5kIGNyeXB0b2dy
YXBoaWMgZGV2aWNlcyB1c2VkIHRvIHN1cHBvcnQgdGhlIENTUCBzZXJ2aWNlcyBmb3IgZmVlZGlu
ZyBpbnRvIHRoZSBDRU4tSVNTUyB3b3JrIG9uIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiBzaWdu
YXR1cmUgcHJvZHVjdHMgLg1UZWNobmljYWwgcmVxdWlyZW1lbnRzIG9uIG9wZXJhdGlvbmFsIGFz
cGVjdHMgb2YgQ1NQcy4NV2hlcmUgYXBwcm9wcmlhdGUsIGlkZW50aWZ5aW5nIGFueSBzcGVjaWZp
YyByZXF1aXJlbWVudHMgb24gUmVnaXN0cmF0aW9uIEF1dGhvcml0eSwgUHJvdmlkZXIgb2YgcmVw
b3NpdG9yeSBmb3IgY2VydGlmaWNhdGVzLCBDU1AgU3RhdGVtZW50cyAgYW5kIG90aGVyIG9uIGxp
bmUgaW5mb3JtYXRpb24sIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Lg1SZXF1aXJlbWVudHMgZm9y
IGFzc2Vzc21lbnQgb2YgQ1NQIGFnYWluc3QgdGhlIHN0YW5kYXJkLiAobGlua2VkIHRvIENFTiBh
Y3Rpdml0eSBvbiBjb25mb3JtYW5jZSkNTG9uZ2VyIFRlcm0gU2NvcGUgDUluIHRoZSBsb25nZXIg
dGVybSAoZS5nLiBvbmNlIGEgZHJhZnQgbWVldGluZyB0aGUgYWJvdmUgcmVxdWlyZW1lbnRzIGlz
IHJlbGF0aXZlbHkgY29tcGxldGUgYW5kIHN0YWJsZSkuIHRoZSB3b3JrIHdpbGwgYmUgZXh0ZW5k
ZWQgdG8gaW5jbHVkZToNdmFyaWF0aW9ucyBpbiB0aGUgQ1NQIHBvbGljeSB0byBtZWV0IHJlcXVp
cmVtZW50cyBmb3IgYWx0ZXJuYXRpdmUgY2xhc3NlcyBvZiBlbGVjdHJvbmljIHNpZ25hdHVyZS4N
cG9saWNpZXMgb2YgQ1NQcyBpc3N1aW5nIENBIGNlcnRpZmljYXRlcyBhbmQgY3Jvc3MgY2VydGlm
aWNhdGVzLg11c2Ugb2YgYWJvdmUgcG9saWNpZXMgYXMgdGhlIGJhc2lzIG9mIHBvbGljaWVzIGZv
ciBvdGhlciBDU1Agc2VydmljZXM6IGF0dHJpYnV0ZSBjZXJ0aWZpY2F0ZXMsIHRpbWVzdGFtcGlu
Zy4NS2V5IFRlcm1zDUNlcnRpZmljYXRpb24gU2VydmljZSBQcm92aWRlciAoQ1NQKQ1FbGVjdHJv
bmljIFNpZ25hdHVyZXMgRGlyZWN0aXZlOiBBbiBlbnRpdHkgb3IgYSBsZWdhbCBvciBuYXR1cmFs
IHBlcnNvbiB3aG8gaXNzdWVzIGNlcnRpZmljYXRlcyBvciBwcm92aWRlcyBvdGhlciBzZXJ2aWNl
cyByZWxhdGVkIHRvIGVsZWN0cm9uaWMgc2lnbmF0dXJlcy4NQ2VydGlmaWNhdGUgUG9saWN5Og1Y
LjUwOTogQSBuYW1lZCBzZXQgb2YgcnVsZXMgdGhhdCBpbmRpY2F0ZXMgdGhlIGFwcGxpY2FiaWxp
dHkgb2YgYSBjZXJ0aWZpY2F0ZSB0byBhIHBhcnRpY3VsYXIgY29tbXVuaXR5IGFuZC9vciBjbGFz
cyBvZiBhcHBsaWNhdGlvbiB3aXRoIGNvbW1vbiBzZWN1cml0eSByZXF1aXJlbWVudHMuIEZvciBl
eGFtcGxlLCBhIHBhcnRpY3VsYXIgY2VydGlmaWNhdGUgcG9saWN5IG1pZ2h0IGluZGljYXRlIGFw
cGxpY2FiaWxpdHkgb2YgYSB0eXBlIG9mIGNlcnRpZmljYXRlIHRvIHRoZSBhdXRoZW50aWNhdGlv
biBvZiBlbGVjdHJvbmljIGRhdGEgaW50ZXJjaGFuZ2UgdHJhbnNhY3Rpb25zIGZvciB0aGUgdHJh
ZGluZyBvZiBnb29kcyB3aXRoaW4gYSBnaXZlbiBwcmljZSByYW5nZS4NUkZDIDI1Mjc6IEFjY29y
ZGluZyB0byBYLjUwOSwgYSBjZXJ0aWZpY2F0ZSBwb2xpY3kgaXMgImEgbmFtZWQgc2V0IG9mICBy
dWxlcyB0aGF0IGluZGljYXRlcyB0aGUgYXBwbGljYWJpbGl0eSBvZiBhIGNlcnRpZmljYXRlIHRv
IGEgcGFydGljdWxhciBjb21tdW5pdHkgYW5kL29yIGNsYXNzIG9mIGFwcGxpY2F0aW9uIHdpdGgg
Y29tbW9uIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4iIEEgY2VydGlmaWNhdGUgcG9saWN5IG1heSBi
ZSB1c2VkIGJ5IGEgY2VydGlmaWNhdGUgdXNlciB0byBoZWxwIGluIGRlY2lkaW5nIHdoZXRoZXIg
YSBjZXJ0aWZpY2F0ZSwgYW5kIHRoZSBiaW5kaW5nIHRoZXJlaW4sIGlzIHN1ZmZpY2llbnRseSB0
cnVzdHdvcnRoeSBmb3IgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uLiAgVGhlIGNlcnRpZmljYXRl
IHBvbGljeSBjb25jZXB0IGlzIGFuIG91dGdyb3d0aCBvZiB0aGUgcG9saWN5IHN0YXRlbWVudCBj
b25jZXB0IGRldmVsb3BlZCBmb3IgSW50ZXJuZXQgUHJpdmFjeSBFbmhhbmNlZCBNYWlsIFtQRU0x
XSBhbmQgZXhwYW5kZWQgdXBvbiBpbiBbQkFVMV0uDUNlcnRpZmljYXRlIFByYWN0aWNlIFN0YXRl
bWVudCAoQ1BTKQ1SRkMgMjUyNyBBIHN0YXRlbWVudCBvZiB0aGUgcHJhY3RpY2VzIHdoaWNoIGEg
Y2VydGlmaWNhdGlvbiBhdXRob3JpdHkgZW1wbG95cyBpbiBpc3N1aW5nICAgICAgY2VydGlmaWNh
dGVzLg1BTlNJIFg5Ljc5OiBBIHN0YXRlbWVudCBvZiB0aGUgcHJhY3RpY2VzLCB3aGljaCBhIGNl
cnRpZmljYXRpb24gYXV0aG9yaXR5IGVtcGxveXMgaW4gaXNzdWluZywgY2VydGlmaWNhdGVzLiBU
aGUgQ1BTIGRlZmluZXMgdGhlIGVxdWlwbWVudCwgcG9saWNpZXMgYW5kIHByb2NlZHVyZXMgdGhl
IENBIHVzZXMgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIHNwZWNpZmllZCBpbiB0aGUgY2Vy
dGlmaWNhdGUgcG9saWNpZXMgdGhhdCBhcmUgc3VwcG9ydGVkIGJ5IGl0Lg1JQ0MgR3VpZGVjOiBB
IHN0YXRlbWVudCBvZiB0aGUgcHJhY3RpY2VzIHdoaWNoIGEgY2VydGlmaWVyIGVtcGxveXMgaW4g
aXNzdWluZyBjZXJ0aWZpY2F0ZXMgZ2VuZXJhbGx5LCBvciBlbXBsb3llZCBpbiBpc3N1aW5nIGEg
cGFydGljdWxhciBjZXJ0aWZpY2F0ZS4ghYUuIFRoZSBzdGF0ZW1lbnQgbWF5IGluY2x1ZGUgYSB0
ZWNobmljYWwgc3RhbmRhcmQsIHJ1bGVzIG9mIHByb2Zlc3Npb25hbCBjb25kdWN0IG9yIHByYWN0
aWNlLCBsYXdzIGFwcGxpY2FibGUgdG8gdGhlIGNlcnRpZmllciwgb3IgYSBicmFuZCBvciBhIG1h
cmsgcmVwcmVzZW50aW5nIG90aGVyIHJ1bGVzIHdpdGggd2hpY2ggdGhlIGNlcnRpZmllciBjb21w
bGllcy4NQ2VydGlmaWNhdGUgUG9saWN5ICB2cyBDUFM6DUFOU0kgWDkuNzk6IA2FLi4gQSBjZXJ0
aWZpY2F0ZSBwb2xpY3kgaXMgYSBoaWdoZXItbGV2ZWwgZG9jdW1lbnQgdGhhbiBhIENQUy4ghS4u
IFRoZSBhcHByb2FjaCBvZiBhIGNlcnRpZmljYXRlIHBvbGljeSBpcyBzaWduaWZpY2FudGx5IGRp
ZmZlcmVudCB0aGFuIGEgQ1BTLiBBIGNlcnRpZmljYXRlIHBvbGljeSBpcyBkZWZpbmVkIGluZGVw
ZW5kZW50bHkgb2YgdGhlIHNwZWNpZmljIGRldGFpbHMgb2YgdGhlIHNwZWNpZmljIG9wZXJhdGlu
ZyBlbnZpcm9ubWVudCBvZiBhIGNlcnRpZmljYXRlIGF1dGhvcml0eSwgd2hlcmVhcyBhIENQUyBp
cyB0YWlsb3JlZCB0byB0aGUgb3JnYW5pemF0aW9uYWwgc3RydWN0dXJlLCBvcGVyYXRpbmcgcHJv
Y2VkdXJlcywgZmFjaWxpdGllcywgYW5kIGNvbXB1dGluZyBlbnZpcm9ubWVudCBvZiBhIGNlcnRp
ZmljYXRlIGF1dGhvcml0eS4gIIUuIA1UaGUgbWFpbiBkaWZmZXJlbmNlIGJldHdlZW4gY2VydGlm
aWNhdGUgcG9saWN5IGFuZCBDUFMgY2FuIHRoZXJlZm9yZSBiZSBzdW1tYXJpemVkIGFzIGZvbGxv
d3M6DSAoYSkJRmluYW5jaWFsIGluc3RpdHV0aW9ucyB0aGF0IG9wZXJhdGUgcHVibGljIG9yIGlu
dGVyHm9yZ2FuaXphdGlvbmFsIGNlcnRpZmljYXRpb24gYXV0aG9yaXRpZXMgbXVzdCBkb2N1bWVu
dCB0aGVpciBvd24gcHJhY3RpY2VzIGluIENQU3MuIFRoZSBDUFMgaXMgb25lIG9mIHRoZSBvcmdh
bml6YXRpb24ncyBtZWFucyBvZiBwcm90ZWN0aW5nIGl0c2VsZiBhbmQgcG9zaXRpb25pbmcgaXRz
IHJlbGF0aW9uc2hpcHMgd2l0aCBzdWJzY3JpYmVycyBhbmQgb3RoZXIgZW50aXRpZXMuIA0oYikJ
QSBjZXJ0aWZpY2F0ZSBwb2xpY3kgYXBwbGllcyBtb3JlIGJyb2FkbHkgdGhhbiB0byBqdXN0IGEg
c2luZ2xlIG9yZ2FuaXphdGlvbmFsIHVuaXQgb3Igc2luZ2xlIG9yZ2FuaXphdGlvbi4gSWYgYSBw
YXJ0aWN1bGFyIGNlcnRpZmljYXRlIHBvbGljeSBpcyB3aWRlbHkgcmVjb2duaXplZCwgaXQgaGFz
IGdyZWF0IHBvdGVudGlhbCBhcyB0aGUgYmFzaXMgb2YgYXV0b21hdGVkIGNlcnRpZmljYXRlIGFj
Y2VwdGFuY2UgaW4gbWFueSBzeXN0ZW1zLg0NDQ0NDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACMDgAAjg4AAG8SAABwEgAAwhUAACMW
AACwFgAAtxYAALgWAADRFgAA1RcAABwYAAAEJQAAKCUAAEklAADaJQAA3yUAAFsnAABjJwAArykA
ALgpAAAbKgAAJSoAACYrAAAwKwAAqywAALUsAABmLgAAaC4AAOYwAAAA/QD7APcA9/T3APAA7OoA
6gDqAOoA6gDqAOoA5gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNQiBS0gcAAM1CIEGNgiBPioBAAdo
CABuSAkEBDBKEAAABzBKEAA2CIEDPioBA0gqAQAeAAQAACAEAAAyBAAASwQAAFgEAAAnBgAASQgA
AHMKAADPCwAAlQwAAOcMAACmDQAARg4AAKUOAACaDwAAtA8AAPoPAAD+DwAAPhAAAF8QAABxEAAA
ghAAAIwQAABwEgAAhRIAAIkUAAAkFQAANxUAALQVAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA
AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAQIABQAACiYAC0YWAAABAAAAAREAABwABAAAIAQAADIEAABLBAAAWAQAACcGAABJCAAA
cwoAAM8LAACVDAAA5wwAAKYNAABGDgAApQ4AAJoPAAC0DwAA+g8AAP4PAAA+EAAAXxAAAHEQAACC
EAAAjBAAAHASAACFEgAAiRQAACQVAAA3FQAAtBUAACQWAABpFgAAphYAANIWAAAmFwAAfBcAAKoX
AAC+FwAAHhgAAPz8/Pz59vPw6uIA39wA2dbT0Pz8/MoAxMG+uACxp52TiX91a2EAAAAAABICDwAG
av3//wgPAAkBCggAAAAAEgIPAAZ+/f//CA8ACQEKBwAAAAASAg8ABqz9//8IDwAJAQoGAAAAABIC
DwAGAv7//wgPAAkBCgUAAAAAEgIPAAZW/v//CA8ACQEKBAAAAAASAg8ABoL+//8IDwAJAQoDAAAA
ABICDwAGv/7//wgPAAkBCgIAAAAAEgIPAAYE////CA8ACQEKAQAAAAANAg8ABnT///8IDwAJAQoC
AgAFAQZR+///AAUG6/3//wUG7////woCAgAFAQYF/v//AAoCAgAFAQbz////AAUGTfT//wUGUfT/
/wUGl/T//wUGsfT//wUGBfb//wUGpfb//w8Gtvf//wgWAAkBCgEAAAAKBnz4//8IFgAJAQAFBtj5
//8FBgL8//8FBiT+//8FBvP///8FAhEABQAAJbQVAAAkFgAAaRYAAKYWAADSFgAAJhcAAHwXAACq
FwAAvhcAAB4YAAA9GQAAURkAAOUZAAANGgAAmRoAANgaAAANGwAAZxsAAAocAABgHAAAyx0AAC0f
AADDHwAAmSAAAO0gAAAnIQAA6iEAACEiAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAO4A
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA7gAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAgAF
DwAKJgALRgAAAAEPAAAFDwANxgUAAWgBAAAbHhgAAD0ZAABRGQAA5RkAAA0aAACZGgAA2BoAAA0b
AABnGwAAChwAAGAcAADLHQAALR8AAMMfAACZIAAA7SAAACchAADqIQAAISIAAOYiAABHIwAAWiMA
AOkjAABMJAAA+/UA6+HXzcrAtqyimI6EenBmXFJMAEIAAAAAAAAAAAAAAAAAEgIPAAZi////CA8A
CQEKGQAAAAAKAgIABQEGLu3//wASAg8ABlv2//8IDwAJAQoYAAAAABICDwAGIPf//wgPAAkBChcA
AAAAEgIPAAZX9///CA8ACQEKFgAAAAASAg8ABhr4//8IDwAJAQoVAAAAABICDwAGVPj//wgPAAkB
ChQAAAAAEgIPAAao+P//CA8ACQEKEwAAAAASAg8ABn75//8IDwAJAQoSAAAAABICDwAGFPr//wgP
AAkBChEAAAAAEgIPAAZ2+///CA8ACQEKEAAAAAASAg8ABuH8//8IDwAJAQoPAAAAABICDwAGN/3/
/wgPAAkBCg4AAAAAEgIPAAba/f//CA8ACQEKDQAAAAAFBjT+//8SAg8ABmn+//8IDwAJAQoMAAAA
ABICDwAGqP7//wgPAAkBCgsAAAAAEgIPAAY0////CA8ACQEKCgAAAAASAg8ABlz///8IDwAJAQoJ
AAAAAAoCAgAFAQY49///AAgCDwAGCv3//xchIgAA5iIAAEcjAABaIwAA6SMAAEwkAACNJAAA+iQA
AAQlAAApJQAAxiUAANolAABbJwAAiikAAK8pAAAbKgAAJisAAI8sAACrLAAAuCwAAGguAADHLgAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPAAAAAA
AAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAAD2AAAAAAAAAAAA
AAAA9gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOwA
AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADsAAAAAAAA
AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAC8AAA3GWQAdyPsw/QEA0AI4BHAIQAsQDuAQsBOAFlAZIBzwHsAhkCRgJzAqAC3QL6AycDVA
OBA74D2wQIBDUEYgSQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDAAABAgAABQ8ADcYF
AAFoAQAAAQAAAAQCAAUkAQYkAQABDwAAFUwkAACNJAAA+iQAAAQlAAApJQAAxiUAANolAABbJwAA
iikAAK8pAAAbKgAAJisAAI8sAACrLAAAuCwAAGguAADHLgAA3C8AAN4wAADfMAAA4DAAAOQwAADl
MAAA5jAAAPbs5gAA4wAA4wDg3dfU0c7LyMUAw8PFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAIBAQAFBrX7//8FBrf8//8FBsz9//8FBiv+//8FBtv///8FBuj///8K
AgMABQIGb/j//wAFBmj+//8FBnP///8FAgMABQIKAgIABQEGe+v//wASAg8ABr7+//8IDwAJAQob
AAAAABICDwAG//7//wgPAAkBChoAAAAXxy4AANwvAADeMAAA3zAAAOAwAADhMAAA4jAAAOMwAADk
MAAA5TAAAOYwAADLAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMkAAAAAAAAAAAAAAADAAAAAAAAA
AAAAAAAAyQAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAADJAAAAAAAAAAAAAAAAyQAAAAAAAAAAAAAA
AMkAAAAAAAAAAAAAAADJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAACQAAFKQAAA3GCAACMxByIAECAAEAAAAzAAAPhDgEEYSY/g3GWQAdyPsw/QEA0AI4
BHAIQAsQDuAQsBOAFlAZIBzwHsAhkCRgJzAqAC3QL6AycDVAOBA74D2wQIBDUEYgSQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAofABIwAB+wgi4gsMZBIbAIByKwCAcjkKAFJJCgBSWwAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEgAKAAEAWwAPAAIAAAAAAAAALgAAQPH/AgAuAAAABgBO
AG8AcgBtAGEAbAAAAAwAAAASZMgAAAAUpGQABABtSAkINgABAAEAAgA2AAAACQBIAGUAYQBkAGkA
bgBnACAAMQAAAAoAAQATpPAAFKQ8AAcANQgBQ0ocAAA2AAJAAQACADYAAAAJAEgAZQBhAGQAaQBu
AGcAIAAyAAAACgACABOk8AAUpDwABwA1CAFDShgAACwAA0ABAAIALAAAAAkASABlAGEAZABpAG4A
ZwAgADMAAAACAAMABgA2CAE+KgEAAAAAAAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBs
AHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAfAD+TwEA8gB8AAAA
CwBCAHUAbABsAGUAdAAgAGwAaQBzAHQAAABTAA8ACiYAC0YPAA3GRwAXIAHQAjgEoAUIB3AI2AlA
C6gMEA54D+AQSBKwExgVgBboF1AZuBogHIgd8B5YIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
HAD+T/L/AQEcAAAABABDAEkAVABFAAAAAwA2CIEAQAA+QAEAEgFAAAAABQBUAGkAdABsAGUAAAAQ
ABEAAyQBE6TwABSkPABAJgATADUIgUNKIABLSBwAT0oCAFFKAgAAAAAAAOYsAAAEAABCAAAAAP//
//8EAAAABCD//wEAAAAAAAAg//8CAAAAAAAEIP//AwAAAAAAACD//wQAAAAAAAAAAAA/DAAAmRYA
AH8kAADmLAAAAAAgAAAAAQA/AAAAAgALAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAgAAAAQAAAAFAAAABQAAAAgAAAAABAAA5jAAABkAAAAABAAAtBUAACEiAADH
LgAA5jAAABoAAAAcAAAAHgAAACAAAAAABAAAHhgAAEwkAADmMAAAGwAAAB0AAAAfAAAAAAAAAC0A
AAAxAAAASwAAAE0AAABwAQAAdAEAAGwCAABwAgAABQYAAAkGAAC0CwAAugsAALsLAADCCwAA4AsA
APkLAAAeDAAAIgwAAGwMAABwDAAA6wwAAO8MAADlDgAA6Q4AAN4UAADiFAAAVBYAAF4WAACTHAAA
lxwAABseAAAfHgAAWCAAAFwgAADsIAAA+CAAAConAAAwJwAAVycAAGAnAAAzKAAAPCgAAHsoAACE
KAAAoygAAKUoAABOKwAAUisAAN8sAADnLAAABwAcAAcABAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAHAAAAAABLAAAAUwAAAPoLAAD9CwAA2RYAANwWAACUGgAAnBoAAN8dAADpHQAA
oh4AALEeAABaHwAAwh8AAMMfAADGHwAA6R8AAPMfAABMIAAAVCAAAI0gAACQIAAAdSEAAIghAACe
IwAApyMAAIkkAACVJAAAACYAABomAACkJgAApSYAAEUnAABUJwAAvScAAMAnAACbKAAApSgAALgo
AAC7KAAA+CgAAPsoAADfLAAA5ywAAAcABAAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa
AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcABwD//xQA
AAAJAE4AaQBjAGsAIABQAG8AcABlADcAQwA6AFwAVwBJAE4ARABPAFcAUwBcAFQARQBNAFAAXABB
AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABFAFQAUwBJAC0AQwBTAFAA
LQByAGYAaQAtAGIALgBhAHMAZAAJAE4AaQBjAGsAIABQAG8AcABlADQARAA6AFwAaABvAG0AZQAt
AHcAbwByAGsAXABUAGUAbQBwAFwARQBUAFMASQAtAE8AUwBMAE8ALQBKAGEAbgAwADAAXABFAFQA
UwBJAC0AQwBTAFAALQByAGYAaQAtAGIALgBkAG8AYwAJAE4AaQBjAGsAIABQAG8AcABlADsARAA6
AFwAVwBvAHIAawBcAEMARQBOAC0ARQBFAFMAUwBJAFwARQBUAFMASQBcAG0AZQBlAHQAaQBuAGcA
XABlAHMAaQAtAGoAYQBuADAAMABcAEUAVABTAEkALQBDAFMAUAAtAHIAZgBpAC0AYgAuAGQAbwBj
AAkATgBpAGMAawAgAFAAbwBwAGUAOwBEADoAXABXAG8AcgBrAFwAQwBFAE4ALQBFAEUAUwBTAEkA
XABFAFQAUwBJAFwAbQBlAGUAdABpAG4AZwBcAGUAcwBpAC0AagBhAG4AMAAwAFwARQBUAFMASQAt
AEMAUwBQAC0AcgBmAGkALQBiAC4AZABvAGMACQBOAGkAYwBrACAAUABvAHAAZQA7AEQAOgBcAFcA
bwByAGsAXABDAEUATgAtAEUARQBTAFMASQBcAEUAVABTAEkAXABtAGUAZQB0AGkAbgBnAFwAZQBz
AGkALQBqAGEAbgAwADAAXABFAFQAUwBJAC0AQwBTAFAALQByAGYAaQAtAGIALgBkAG8AYwAJAE4A
aQBjAGsAIABQAG8AcABlADsARAA6AFwAVwBvAHIAawBcAEMARQBOAC0ARQBFAFMAUwBJAFwARQBU
AFMASQBcAG0AZQBlAHQAaQBuAGcAXABlAHMAaQAtAGoAYQBuADAAMABcAEUAVABTAEkALQBDAFMA
UAAtAHIAZgBpAC0AYgAuAGQAbwBjAAkATgBpAGMAawAgAFAAbwBwAGUATgBEADoAXABXAG8AcgBr
AFwAQwBFAE4ALQBFAEUAUwBTAEkAXABFAFQAUwBJAFwARQBUAFMASQAtAEUAZQBzAHMAaQAtADIA
XAB0AGEAcwBrADEALQBpAG4AaQB0AGkAYQBsAC0AZgByAGEAbQBlAHcAbwByAGsAXABFAFQAUwBJ
AC0AQwBTAFAALQByAGYAaQAtAGIALgBkAG8AYwAJAE4AaQBjAGsAIABQAG8AcABlAC8AQwA6AFwA
VABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEUAVABT
AEkALQBDAFMAUAAtAHIAZgBpAC0AYgAuAGEAcwBkAAkATgBpAGMAawAgAFAAbwBwAGUAOgBEADoA
XABXAG8AcgBrAFwAQwBFAE4ALQBFAEUAUwBTAEkAXABFAFQAUwBJAFwARQBUAFMASQAtAEUAZQBz
AHMAaQAtADIAXABSAEYASQBcAEUAVABTAEkALQBDAFMAUAAtAHIAZgBpAC0AYwAuAGQAbwBjAAkA
TgBpAGMAawAgAFAAbwBwAGUAGgBDADoAXABUAEUATQBQAFwARQBUAFMASQAtAEMAUwBQAC0AcgBm
AGkALQBjAC4AZABvAGMAFgB8////7OziZf8P/w//D/8P/w//D/8P/w//DwEAff///yAvVBz/D/8P
/w//D/8P/w//D/8P/w8BAH7///8e7bz4/w//D/8P/w//D/8P/w//D/8PAQB/////aEoa0/8P/w//
D/8P/w//D/8P/w//DwEAgP///2idOP//D/8P/w//D/8P/w//D/8P/w8BAIH////Ajk47/w//D/8P
/w//D/8P/w//D/8PAQCC////9Nxo0P8P/w//D/8P/w//D/8P/w//DwEAg////yg7Qr3/D/8P/w//
D/8P/w//D/8P/w8BAIj///+ax64X/w//D/8P/w//D/8P/w//D/8PAQCJ////5hCo8/8P/w//D/8P
/w//D/8P/w//DwEA/v//////////DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAWHaa9/w8AAAAAAAAA
AAAAAAAAAAAAAQCPT0EBAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAKCAuAwEACQT/DwAAAAAAAAAA
AAAAAAAAAAABAEQhBAWUmJbVDwAAAAAAAAAAAAAAAAAAAAAAAQB0T+oOAQAJBP8PAAAAAAAAAAAA
AAAAAAAAAAEATVbrPwEACQT/DwAAAAAAAAAAAAAAAAAAAAABAFom+EsBAAkE/w8AAAAAAAAAAAAA
AAAAAAAAAQD+CuFMAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAXCj2VAEACQT/DwAAAAAAAAAAAAAA
AAAAAAABAA8gGVsBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQAhdVBpCJ1Klf8P/w//D/8P/w//D/8P
/w//DwEAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E1AURhJj+FcYFAAHUBQYCAAAALgAB
AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4S5BBGEmP4VxgUAAbkEBgIAAAAuAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAQAAAPhJ4DEYSY/hXGBQABngMGAgAAAC4AAQAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAABAAAA+EgwIRhJj+FcYFAAGDAgYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAA
AAALEAAAD4TUBRGEmP4VxgUAAdQFBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsQAAAPhLkEEYSY/hXGBQABuQQGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA
AAAAAAAACxAAAA+EngMRhJj+FcYFAAGeAwZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAALEAAAD4SDAhGEmP4VxgUAAYMCBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAA
AAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAA
AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQAqAAEAAAAXAAAAAAAAAAAAAAAgAQAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG
T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo
AQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA
AWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAgAQAAAAAAAAsQAAAPhGgBEYSY/hXG
BQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+
FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE
mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB
EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E
aAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA
D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ
AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwFAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA
CxAAAA+ElQERhJj+FcYFAAGVAQZPSgEAUUoBAG8oAAEAt/AWAAAAAQAAAAAAAAAAAAAAAAAAAE1W
6z8AAAAAAAAAAAAAAACPT0EBAAAAAAAAAAAAAAAAif///wAAAAAAAAAAAAAAAIP///8AAAAAAAAA
AAAAAACC////AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAAAID///8AAAAAAAAAAAAAAACI////
AAAAAAAAAAAAAAAAf////wAAAAAAAAAAAAAAAH7///8AAAAAAAAAAAAAAAB9////AAAAAAAAAAAA
AAAAfP///wAAAAAAAAAAAAAAAP7///8AAAAAHIbrAAEAAABEIQQFAAAAAAAAAAAAAAAA/grhTAAA
AAAAAAAAAAAAAA8gGVsAAAAAAAAAAAAAAAB0T+oOAAAAAAAAAAAAAAAAXCj2VAAAAAAAAAAAAAAA
ACggLgMAAAAAAAAAAAAAAABaJvhLAAAAAAAAAAAAAAAAIXVQaQAAAAAAAAAAAAAAAP//////////
////////////////////////////////////////////////////////////////KIbrACAAAAAB
AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RjARGEmP5PSgEAUUoBAG8oAAEAt/D/////////
////////////////////////////////////FgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA/0ABgAEASwAAAEsAAADE1+sAAQABAEsAAAAAAAAASwAAAAAAAAAC
EAAAAAAAAADmLAAAQAAACABAAAADAAAARxaQAQAAAgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACf
AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAA
AAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAA
AAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAAACIABABBCIwAAADQAgAAaAEAAAAAlsxBRobU
QWYAAAAAAwACAAAAfQYAAP8kAAAEABIAAAAEAIMQTgAAAAAAAAAAAAAABAABAAAAAQAAAAAAAABE
JAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAMjAAABEAGQBkAAAAGQAA
AG8tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgAAAGYC//8SAAAAAAAAAB8ARQBUAFMASQAgAEUAUwBJACAAEyAgAEUARQBT
AFMASQAgAFcAbwByAGsAIABQAHIAbwBnAHIAYQBtAG0AZQAAAAAAAAAJAE4AaQBjAGsAIABQAG8A
cABlAAkATgBpAGMAawAgAFAAbwBwAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA
AHgBAAAQAAAAAQAAAIgAAAACAAAAkAAAAAMAAAC4AAAABAAAAMQAAAAFAAAA2AAAAAcAAADkAAAA
CAAAAPgAAAAJAAAADAEAABIAAAAYAQAACgAAADQBAAAMAAAAQAEAAA0AAABMAQAADgAAAFgBAAAP
AAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAA5AQAAB4AAAAgAAAARVRTSSBFU0kgliBFRVNTSSBX
b3JrIFByb2dyYW1tZQAeAAAAAQAAAABUU0keAAAACgAAAE5pY2sgUG9wZQAgRR4AAAABAAAAAGlj
ax4AAAALAAAATm9ybWFsLmRvdABFHgAAAAoAAABOaWNrIFBvcGUAAEUeAAAAAgAAADMAY2seAAAA
EwAAAE1pY3Jvc29mdCBXb3JkIDguMAByQAAAAACMhkcAAAAAQAAAAACU7hFhZ78BQAAAAAD0IwAo
aL8BAwAAAAQAAAADAAAAfQYAAAMAAAD/JAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4b
EJOXCAArLPmuYAEAABwBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAA
oAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAAD8
AAAAAgAAAOQEAAAeAAAAFQAAAFNlY3VyaXR5ICYgU3RhbmRhcmRzAABJAAMAAABOAAAAAwAAABIA
AAADAAAAby0AAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA
ACAAAABFVFNJIEVTSSCWIEVFU1NJIFdvcmsgUHJvZ3JhbW1lAAwQAAACAAAAHgAAAAYAAABUaXRs
ZQADAAAAAQAAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABf
UElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsANQAxADkAQgBDADEANQAwAC0AQQA0ADAANwAtADEA
MQBEADMALQBCADUAMwBDAC0AMAAwADEAMAA1AEEAQgBFADIAOAA1ADEAfQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA
AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA
ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA
HwAAACAAAAAhAAAA/v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAt
AAAA/v///y8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAD+////NwAAADgAAAA5AAAAOgAAADsA
AAA8AAAAPQAAAP7////9////QAAAAP7////+/////v//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////9SAG8AbwB0
ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
FgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA8DNx6CdovwFwY54FKGi/AUIAAACA
AAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAIgAAAD4XAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIUIAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYA
bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA////
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4AAAAAEAAAAAAAAAUARABvAGMA
dQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4
AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANgAAAAAQ
AAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAA
AAAAAAAAcGOeBShovwFwY54FKGi/AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////8BAP7/AwoAAP//
//8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmRE
b2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

------=_NextPart_000_0015_01BF6CCC.1AE581C0--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05737 for <[e-mail]>; Tue, 1 Feb 2000 08:54:16 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id IAA16487; Tue, 1 Feb 2000 08:52:55 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <DZYZ49BR>; Tue, 1 Feb 2000 08:55:04 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Juan Rodriguez-Torrent'" <[e-mail]>, [e-mail], Russ Housley <[e-mail]>
Subject: RE: OCSP and CSL
Date: Tue, 1 Feb 2000 08:55:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0015_01BF6CAB.57348390"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BF6CAB.57348390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>Russ, I cannot agree more. I'm just trying to figure out if these are
real
>customer requirements or some folks in a glass house tinkering with
>possibilities.

Juan,

	Now that we have real customers doing real business with PKI it
may 
be time to start improving PKIX by throwing out features that are in 
widespread disuse and pare down the schemas to a manageable size. 

	We can anticipate equal success for our researches into porcine 
aviation.

		Phill

------=_NextPart_000_0015_01BF6CAB.57348390
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDIwMTE2NTYxNFowIwYJKoZI
hvcNAQkEMRYEFCAXDITu9eQFODrXl5X3D1Uw7OJ8MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGARPFyOrnSpKRCckDxiITjRWnsY3xDg8u+bn5LxpxJ/Q8H1iDmmjbhQUAxmILIjfCj
qD4+XiZdQsCFh2W8VebiuoCeT/2/BQPVkmisXa3mVJ+jLtteBNbXcyD5kWXgLsAD/hmtPakGXOLT
KdBGl8qKvYo3VtgpsG237BJSHd4NlHsAAAAAAAA=

------=_NextPart_000_0015_01BF6CAB.57348390--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02296 for <[e-mail]>; Tue, 1 Feb 2000 07:30:10 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id HAA10074; Tue, 1 Feb 2000 07:29:19 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <DZYZ471M>; Tue, 1 Feb 2000 07:31:28 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Linn, John'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Tue, 1 Feb 2000 07:31:27 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01BF6C9F.A9A9A350"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF6C9F.A9A9A350
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This attack can be corrected by using the 'exposed MAC' I proposed
in the HTTP security working group in '93 (yahh boo sucks to patent
squaters).

Essentially what one does is to use a MAC to digest the document (I
referred to it as a keyed digest in the prior art). Then one publishes
the key to the MAC along with the digest.

The advantage of this particular scheme is that you can use it to 
harden a system against even exhaustive search (brute force) attacks
with a little ingenuity.


		Phill


-----Original Message-----
From: Linn, John [mailto:[e-mail]]
Sent: Monday, January 31, 2000 4:05 PM
To: '[e-mail]'
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt


I've a few comments on this specification.

If different entities obtain timestamps on the same data object using
the
same hash algorithm, or a single entity obtains multiple timestamps on
the
same object, the generated timestamp tokens will include identical
message
imprints; as a result, an observer could determine that the timestamps
refer
to the same underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential exposure
is a
concern, some unique value could be generated by the requester and
combined
with a data object before hashing the combination in order to produce
MessageImprint's hashedMessage. 

The second paragraph of Sec. 2.2 bears a number of SHALLs for
verification
steps which are to be performed by the requesting entity once the
TimeStampToken is received.  What's the recommended or required action
if
any of these verifications fail? 

In the Accuracy structure, is no more than one of the seconds, millis,
or
micros OPTIONALs to occur, or may more than one of these elements occur
in
combination? 

In References, [ESS] is now RFC-2634.

Editorially, there's an odd character which seems to recur instead of
the
apostrophe in the phrase "TSA's", and in other places where an
apostrophe or
closing single quote is intended; on my display, it appears as a
ligature
"AE".

Other, minor editorial points:

p. 8, 1st line, "may to be used" -> "may be used".

Later on p. 8, "subtracting the accuracy to" -> "subtracting the
accuracy
from". 

Appendix A, 4th line, "allows to know" -> "allows a verifier to know".

--jl

------=_NextPart_000_0005_01BF6C9F.A9A9A350
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDIwMTE1MzIzOVowIwYJKoZI
hvcNAQkEMRYEFE/taJZ3z7uCKVrtB9/UI+ESjeqNMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAa0bDKGRXuRUe60mZaLjWuvrfJQa+rtgALkX+pBzhDg+S+PCBWTQ5Hi1MA4g5yxVu
QvQ9WIU3Kr/KXye4a2FmZiGQZHfVCH5PqJKdD/XdW15C+kPVxFttvEZpJNxogZlOLFOhr4zePf0l
GDlnl3K+YMpPXPp1ZEjENpJGTpd63E4AAAAAAAA=

------=_NextPart_000_0005_01BF6C9F.A9A9A350--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28311 for <[e-mail]>; Tue, 1 Feb 2000 06:34:01 -0800 (PST)
Received: from bbn.com (TC109.BBN.COM [128.33.238.109]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA17530 for <[e-mail]>; Tue, 1 Feb 2000 09:36:14 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 01 Feb 2000 09:36:26 -0500
From: Christopher Owens <[e-mail]>
Reply-To: [e-mail]
Organization: BBN Technologies, a part of GTE Corporation
X-Mailer: Mozilla 4.51 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Unsubscribe [e-mail]
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

Unsubscribe

Unsubscribe [e-mail]