headers
Peter Gutmann | 1 Jun 2001 12:14
Picon
Picon
Picon
Favicon

RE: Minor OID mistakes in OCSPv2 and the official OID list

"Michael Myers" <mike <at> traceroutesecurity.com> writes:

>I (and I hope others too) deeply appreciate what Paul's doing for us but in
>the longer run I'm little bit concerned of direct linkage to a potentially
>ephemeral Web site.

As opposed to a non-ephemeral IETF draft?

Peter :-).
Permalink | Reply | 1 comment |
headers
Peter Williams | 1 Jun 2001 02:48

RE: cA flag and CRL issuers

I think this was very good news.

Let me put Steve's apparent statements in simpler, declarative form
in which each numbered assertion is a self-contained truth devoid
of context, other than perhaps assuming the truth of an earlier 
numbered assertion:

1. OCSP can be used in side-effect modes.

2. It is legitimate to use OCSP responder working in a
side effect mode to achieve the goals T&B cite

3. You can "rely" on an OCSP responder/response.

4. You can combine an OCSP side effect mode with reliance
on an OCSP responder/respose.

5. A relying party can rely upon an OCSP responder working
in side effect mode "V" as "a local means of asserting per-certificate
validity
judgements that might override those of the CA who issued a cert."

6. To use and rely on an OCSP responder operating in side effect
mode "V" is to be operating in a manner compatible with the PKIX
overall model.

7. The same general theory holds for a DPV server.

Do you agree that some or all of my numbered assertions are consistent
with Steve's message, as you intepreted it?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Hoffman / IMC | 1 Jun 2001 02:48
Picon

RE: Minor OID mistakes in OCSPv2 and the official OID list

At 2:44 PM -0700 5/31/01, Michael Myers wrote:
>I (and I hope others too) deeply appreciate what Paul's doing for us but in
>the longer run I'm little bit concerned of direct linkage to a potentially
>ephemeral Web site.  I recall my aggravation years ago at having to hunt
>down authoritative references to OIW OIDs.

So, you got a few choices:

- Let { Paul | Tim | Steve | Russ | Peter :-) | someone } keep it on 
a web site that is hopefully well-known

- Put it in an Internet Draft that has to be updated at least every 
six months and is hopefully well-known

- Put it into an RFC that will be well-known but won't change

- Make it an IANA registry

The last one is preferable, if and only if we can come up with a 
clear and sensible mechanism for IANA to follow. That is the 
difficult part. This thread shows exactly how hard it is. The IANA 
folks are good record keepers, and they don't know diddly about ASN.1 
or PKIX, nor do they want to learn about it.

Probably the best way to let IANA run it is to have them not do the 
management, but to have an "OID reviewer" run a mailing list and that 
person is the only one who can tell IANA how the registry should 
change. This is essentially what we are doing now, except that the 
registry is on a web server somewhere, not at IANA. At the point we 
think the registry is well-cooked, someone must write an Internet
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hideyuki Odahara | 1 Jun 2001 03:30
Picon

Re: draft-ietf-pkix-ac509prof -> RFC?

Sir

Thank you for an instant reply. 
Although not soon set easily to RFC, saying soon,
it is waiting to be set to RFC with expectation after this.
Moreover, since a question will be asked if there are some
questions, please let me know then. 

Thanks

----------
  Hideyuki Odahara ： odahara <at> dsa.isl.ntt.co.jp

> Hi,
> 
> I'm not entirely clear exactly what question is being asked, 
> however, I *think* the answer is that I've got to make a few
> very minor changes and then that draft will be sent to the RFC 
> editor. In other words, the work on this specification is done, 
> it will be an RFC quite soon now, without any substantive 
> changes being made.
> 
> The minor changes to be made include adding a section saying 
> that there are no IANA consideration; updating to reflect a 
> couple of minor changes to the base X.509 document and a change 
> to allow some s/mime specifications to reference this document
> more easily.
> 
> I hope that answers your question,
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Myers | 1 Jun 2001 06:17

RE: Minor OID mistakes in OCSPv2 and the official OID list

Paul,

This is actually what I had in mind in the long run, an IANA level doc.  I
for one think we're close enough to get the machinery moving but I'm
deferring to you and Russ and whomever else to come back and say whether
that's a feasible thing to do or not right now.

Mike

> -----Original Message-----
> From: Paul Hoffman / IMC
>
> . . .
>
> - Make it an IANA registry
>
> . . .
>
> [etc. re: IANA]
>
> . . .
>
> Do we think we are ready enough for that yet?
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Jun 2001 12:48
Picon
Favicon

I-D ACTION:draft-ietf-pkix-rfc2511bis-02.txt

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Request Message Format (CRMF)
	Author(s)	: M. Myers, C. Adams, D. Solo, D. Kemp
	Filename	: draft-ietf-pkix-rfc2511bis-02.txt
	Pages		: 25
	Date		: 31-May-01
	
This document describes the Certificate Request Message Format
(CRMF).  This syntax is used to convey a request for a certificate to
a Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc2511bis-02.txt".

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

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Jun 2001 12:47
Picon
Favicon

I-D ACTION:draft-ietf-pkix-rfc2510bis-04.txt

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-04.txt
	Pages		: 90
	Date		: 31-May-01
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc2510bis-04.txt".

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

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nada Kapidzic Cicovic | 1 Jun 2001 14:18

Fwd: I-D ACTION:draft-ietf-sacred-pkienrollinfo-00.txt

Let me draw your attention to a new draft that has been published by IETF 
Sacred WG:
draft-ietf-sacred-pkienrollinfo-00.txt.

It describes a proposal for providing RA/CA PKI parameters available to EEs 
prior to initial EE initiated certification. The creation of this draft was 
initiated during PKI Forum/ICSA driven CMP testing.

It relies heavily on PKIX RFCs and drafts, but has been published as Sacred 
draft due to the fact that it describes information that is to be stored in 
EE's PSE/token, which belongs to Sacred rather than PKIX.

Please send your comments and suggestions either directly to me or to 
sacred mailing list (ietf-sacred <at> imc.org). Note that I will not be able to 
respond to my mail in mid/end of June.

Thanks,
Nada

>To: IETF-Announce: ;
>Cc: ietf-sacred <at> imc.org
>From: Internet-Drafts <at> ietf.org
>Reply-to: Internet-Drafts <at> ietf.org
>Subject: I-D ACTION:draft-ietf-sacred-pkienrollinfo-00.txt
>Date: Fri, 01 Jun 2001 06:48:10 -0400
>Sender: owner-ietf-sacred <at> mail.imc.org
>List-Archive: <http://www.imc.org/ietf-sacred/mail-archive/>
>List-Unsubscribe: <mailto:ietf-sacred-request <at> imc.org?body=unsubscribe>
>List-ID: <ietf-sacred.imc.org>
>HOP-COUNT: 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlin Covey | 1 Jun 2001 15:56

RE: draft delta crl text

Tim,

A commendable job, but I do have a comment concerning the following
portion of the text:

"For each certificate whose status has changed since the generation
of the referenced base CRL:

      (a)  If the certificate is revoked for a reason included in the
      scope of the CRL, list the certificate as revoked.

      (b)  If not (a), list the certificate with the reason code
      removeFromCRL."

Rule (a) is fine, but unfortunately rule (b) catches more certificates
in its net than was intended.  A literal reading implies that
certificates should be listed with reason code removeFromCRL if their
status has changed in any way at all, e.g. newly created certificates,
newly expired certificates, and even revoked or "removed from hold"
certificates that are not within the scope of the CRL.  (These are all
certificates whose status has changed that are "not (a)" )

Here's a suggestion for rule (b):

       If the certificate was previously listed on the referenced base
       CRL or a subsequent delta CRL with reason code certificateHold,
       and that certificate is no longer on hold, list the certificate
       with the reason code removeFromCRL.

By the way, although this is fairly obvious, for the sake of completeness
(Continue reading)

Permalink | Reply | 0 comments |
headers
David P. Kemp | 1 Jun 2001 15:29

Re: cA flag and CRL issuers

Peter,

I agree with your seven assertions, with two caveats to number 6:

a) The OCSP and DPV documents should make an explicit declaration that
there are three, not two, modes of operation:
  1) Authorized,
  2) Trusted to provide CA status,
  3) Trusted to provide locally-determined status.

b) Third-party OCSP providers (those operated under the administrative
control of some entity other than the one responsible for approving RP
trust anchors) should be required to make available a CP, CPS, or
equivalent to all customer RPs, and that document must make an explicit
statement that the provided OCSP responses are "always consistent" or
"possibly inconsistent" with the status provided by the certificate
issuer.

I believe the PKIX model accommodates a local mode of online
status operation as long as there is full disclosure.  I believe the
PKIX model accommodates only Authorized signers of CRLs.

Dave

Peter Williams wrote:
> 
> I think this was very good news.
> 
> Let me put Steve's apparent statements in simpler, declarative form
> in which each numbered assertion is a self-contained truth devoid
(Continue reading)

Permalink | Reply | 2 comments |

Gmane