RE: DISCUSS: MUST reject in OCSPv1

Re: Straw poll: An advice to a commercial CA

Absolutely correct.  "Typical users", and their user agent software, 
have no threat model against which to apply any sort of security policy, 
and therefore have no reason to demand certificates containing policy 
OIDs or configuration interfaces more complex than the "Whatever" button.

Typically only organizations have security policies, and therefore 
organizations are the only relying parties with a need to configure the 
strength of authentication they are willing to accept.  If there were a 
standardized set of certificate policies (analogous to gasoline octanes, 
or USDA beef grades Choice and Select), then users could select among 
competing commercial CAs providing a certain grade of product.  But 
unless banks or other e-businesses start requiring users to have Choice 
(but not Select) third-party certificates to access their accounts, 
users have no reason to obtain such certificates or to care how much 
assurance they provide.

Dave

Christine Karman wrote:
> At 12:27 11-27-03, Peter Gutmann wrote:
> 
>> To answer an earlier question about support for policy restrictions, 
>> cryptlib
>> supports these (policy constraints with all its weird variations).  If
>> cryptlib finds constraints in a CA cert it'll apply them down the 
>> chain, but
>> there's no way for a user to configure the behaviour.  The reason for 
>> this is
>> that no-one has ever asked for this [0], so I can't even begin to 
>> imagine what
>> sort of interface it'd require to manage things.  Do users type in a 
>> list of
>> OIDs from a piece of paper?  Do they click on a CA cert and say "Use the
>> policies advertised by this CA"?
> 
> 
> Typical users hardly know what a CA is. They don't know what kind of 
> policies you are talking about. So a GUI would assume a most probable 
> strategy, and then prompt the user with "I recommend you adopt policy 
> xyz for this certificate. Press 'OK', or press 'advanced' to change". On 
> a company level, a system administrator would force a certain behavior 
> of the GUI, which cannot be changed by individual users.
> Having said this, the GUI would probably make the choice by itself, 
> because user interaction suggests that the user makes a decision on the 
> subject, while in reality the user just presses a button that may as 
> well read "Whatever".
> I agree, this is not what the world should be like. But it is.
> 
> dagdag
> Christine
> -- 
> Izecom BV
> Secure e-mail and digital signatures
> www.izecom.com

RE: DISCUSS: MUST reject in OCSPv1

It looks like I've missed most of the fun, but here are my thoughts in
any case...

For the record, I would object to any v1 addition that would mandate a
"MUST reject" clause.

As for the nonceUnsupported proposal, it does have it merits.  However I
have to agree with Ryan by objecting to its standardization in v1 for
two reasons.  First, doing so will not allow for the "TLS Extension" use
case where OCSP responses are included in protocol exchanges.  Second,
it will make currently conformant clients, non-conformant.  I'm also
worried that such a large change to v1 now will break some
implementations.  

I'm happy to have discussions on these issue in the context of a v2
protocol.  But would suggest we leave v1 as it is.  

Alex

> -----Original Message-----
> From: Marc Branchaud [mailto:marcnarc <at> rsasecurity.com] 
> Sent: Friday, November 28, 2003 2:23 PM
> To: ietf-pkix <at> imc.org
> Subject: Re: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Mike just gave me an offline whack to the head.
> 
> I have no objection to the original nonceUnsupported proposal, as 
> described in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
> including David's "return an error" addition in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html
> 
> Having clarified my earlier clarification, I wish to reset the 
> conversation...
> 
> Florian: As we both support the proposal, we may be in danger 
> of violent 
> agreement.
> 
> Ryan: Your arguments have failed to convince me that the 
> proposal is bad.
> 
> Apologies to all for the churn.
> 
> 		M.
> 
> 
> Michael Myers wrote:
> > Marc,
> > 
> > The proposal is to cycle *v1* at Proposed to address this one issue.
> > We would also take the opportunity to clarify encoding of nonce
> > as OCTET STRING, which was going to happen anyway as v1 went
> > from
> > Proposed to Draft.
> > 
> > I take it then you have no objection to the core technical 
> aspects of 
> > the proposed resolution?
> > 
> > Mike
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ietf-pkix <at> mail.imc.org 
> >>[mailto:owner-ietf-pkix <at> mail.imc.org]On Behalf Of Marc Branchaud
> >>Sent: Friday, November 28, 2003 10:28 AM
> >>To: ietf-pkix <at> imc.org
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Marc, your response was ambiguous.
> >>
> >>Just to clarify, then:
> >>
> >>The resolution started with a "big if": Cycling at
> >>proposed.  I have no
> >>objection to cycling at Proposed and issuing an
> >>OCSPv2 that works all
> >>this out.
> >>
> >>It's the "then" I am objecting to.  The proposed
> >>"then" is bad.
> >>
> >>		M.
> >>
> > 
> > 
> 

An advice to a commercial CA

A root key always deserves the lowest level of trust since whatever it 
signs is accepted by the RP.
The clue of the matter is that the RP should not just accept the root, 
but instead the issuing CA as trusted issuing party.
an example

tree / liability
-----/ -----
root / 0
signs  
bronze / 0
signs
silver / 1'000
signs
gold / 10'000
signs
platinum / 100'000
signs
qualified /  1'000'000

with this hierarchy an RP can say "my application (ex: web shop) 
requires silver or better" and thus accept the silver CA. If an RP 
decides to only accept gold level certs (for whatever reason, maybe 
liability) he should never accept the Root key.

This way a CA can decide to provide requesters with a certain level of 
certificate, meant for certain types of transactions (buying a CD vs 
booking hollidays vs or e-voting). And thus fullfill a business case.
The requesters can choose to purchase a cert of a certain quality 
allowing for certain types of transactions independent from the provider 
of these certs.
The RP can look at the cert and base his sell or no-sell decission on 
the cert quality. Also becomming independent of the issuing party.

All this requires, is a verifyable definition of Bronze, Silver, Gold, 
Platinum, Qualified. All issuing parties that are able to offer certs of 
a certain level get "audited" regularly and published to provide 
subscribers and RP's a decission aid. Issuing parties no longer being 
able to offer a certain quality loose their "quality seal" and probably 
their subscribers

regarding the the two different "expensive" issuances.
Here in detail it actually looks like this

signs
silver
signs
silver P(ersonal) and silver S(ervices) and X(xxx)..... and
Gold

Silver, with its sub CA's becomes a level having certain characteristics 
like liability. Thus organisations can choose for a certain level and 
then outsource their entire PKI realizing that registration, liability 
and whatever other elements are important, fit their requirements. This 
is very attractive for an industry that thus becomes independent of CA's 
while determining the minimum requirements of the certs they are willing 
to work with.

RP's actually like this. All they have to decide on is what level of 
certs they are willing to accept. if the cert is of the right level the 
root key of the issuing party no longer matters! trust is based on cert 
quality.



Looking forward to any feedback

Josh

Anders Rundgren wrote:

>Doesn't your scheme make an RP trusting the "expensive" CA
>also trust the "cheap" CA as they share a common root?
>
>And there could also be just two different "expensive" issuances
>that are incompatible like server-side SSL certs and certs for
>individuals.
>
>It looks to me that you move potential problems to the RP SW.
>Mathematically OK? For sure.  Standards-compliant?  For sure.
>But working?  Under strictly monitored conditions only.  Such
>conditions are unlikely to be met when you start to count RPs
>in the thousands and up.
>
>Anyway. several other folks on the list seem to agree that
>such schemes (including policy OID-enhanced path validation)
>only work in "managed" or "community" based PKIs.
>
>In my opinion the need for standards is much more evident
>in "unmanaged" spaces.
>
>Anders
>
>----- Original Message -----
>From: "Joseph Doekbrijder" <joseph.doekbrijder <at> swisssign.com>
>To: "Anders Rundgren" <anders.rundgren <at> telia.com>
>Cc: "Stephen Kent" <kent <at> bbn.com>; <ietf-pkix <at> imc.org>
>Sent: Thursday, November 27, 2003 10:43
>Subject: Re: Straw poll: An advice to a commercial CA
>
>
>Only logical thing to do is a single root, signing the cheap CA which in
>its turn signs the expensive CA.
>Mathematically correct, includes trust logic, liability levels etc, etc...
>
>This is how we do it. 
>
>Cheers
>
>Josh
>
>
>Anders Rundgren wrote:
>
>  
>
>>Well,
>>Since the list is close to "vibrant" with emotions, why not
>>put RFC3280 through the litmus test?
>>
>>Assume that you as PKI professionals would advice a commercial
>>TTP CA on how to configure their issuance for the following:
>>1. Free e-mail roundtrip-verification certficates.  Low insurance level
>>2. Expensive (high insurance level) multi-usage certificates for individuals
>>using strong verification procedures.
>>
>>Note: the service is to be launched ASAP and has the only
>>objective, making money by serving its subscribers well.
>>
>>Indicate your advice by the word in uppercase.
>>
>>SINGLE: A single root + possibly some CP OIDs to spice things up
>>MULTIPLE: Different roots
>>
>>Lets rock!
>>
>>
>>
>>    
>>
>--
>Joseph A. Doekbrijder
>--------------------------------------------------
>SwissSign AG
>Löwenstrasse 1, CH-8001 Zürich
>Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
>www.swisssign.com
>--------------------------------------------------
>
>
>  
>

--

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 43 344 88 11 Mobil: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

RE: DISCUSS: MUST reject in OCSPv1

I am not very happy with the way that this discussion is going.  I am not 
convinced that a new extension is the best compromise.

I have just reread the nonce-related portions of RFC 2560.  I must say, it 
is quite under specified.  It does not even provide a syntax for a 
nonce.  It really only provides the OID to identify the nonce extension and 
which extension location in which it is carried.

It says:

    The nonce cryptographically binds a request and a response to prevent
    replay attacks. The nonce is included as one of the requestExtensions
    in requests, while in responses it would be included as one of the
    responseExtensions. In both the request and the response, the nonce
    will be identified by the object identifier id-pkix-ocsp-nonce, while
    the extnValue is the value of the nonce.

    id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

Rather than defining a new extension, called nonceUnsupported, you have the 
opportunity to specify a syntax to go with this OID that does the same 
thing.  Something like:

    OCSPNonce ::= CHOICE {
       nonceValue  OCTET STRING,
       unsupported  NULL }

Text that goes with the syntax definition ought to make it illegal for the 
request to use the NULL.  That is, it is only allowed in the response.

I still prefer the "MUST reject" approach, but this seems like a cleaner 
solution than a new extension.

Russ

Ambarish wrote:

>Hi Florian,
>    The reason for including a nonce in the request is to enable a
>client that doesn't have a very precise knowledge of time to still
>be sure the response he got from the server was generated for this
>specific request.
>
>While I do agree with Mark and think that the "right" way would be
>to require the client to require the nonce in the response, in the
>interests of moving ahead, I vote to accept Mike's compromise
>proposal that a client MUST require the nonce in the response
>unless it is accompanied by a nonceUnsupported extension in
>the response and the client is willing to accept a response w/o
>a nonce. This preserves the semantics for current clients and
>still allows caching servers to supply responses to clients
>who will take them.
>
>Regards,
>Ambarish

RE: DISCUSS: MUST reject in OCSPv1

Russ,

So if I'm reading this correctly, a server that receives a
request containing a value for nonceValue MAY ignore the nonce
and return NULL?

By the way, Ambarish and I had already planned to clarify nonce
syntax as OCTET STRING as 2560 goes from Proposed to Draft.

Mike

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
> [mailto:owner-ietf-pkix <at> mail.imc.org]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
> To: ietf-pkix <at> imc.org
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> I am not very happy with the way that this discussion
> is going.  I am not
> convinced that a new extension is the best compromise.
>
> I have just reread the nonce-related portions of RFC
> 2560.  I must say, it
> is quite under specified.  It does not even provide a
> syntax for a
> nonce.  It really only provides the OID to identify
> the nonce extension and
> which extension location in which it is carried.
>
> It says:
>
>     The nonce cryptographically binds a request and a
> response to prevent
>     replay attacks. The nonce is included as one of
> the requestExtensions
>     in requests, while in responses it would be
> included as one of the
>     responseExtensions. In both the request and the
> response, the nonce
>     will be identified by the object identifier
> id-pkix-ocsp-nonce, while
>     the extnValue is the value of the nonce.
>
>     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= {
> id-pkix-ocsp 2 }
>
> Rather than defining a new extension, called
> nonceUnsupported, you have the
> opportunity to specify a syntax to go with this OID
> that does the same
> thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }
>
> Text that goes with the syntax definition ought to
> make it illegal for the
> request to use the NULL.  That is, it is only allowed
> in the response.
>
> I still prefer the "MUST reject" approach, but this
> seems like a cleaner
> solution than a new extension.
>
> Russ
>
>
> Ambarish wrote:
>
> >Hi Florian,
> >    The reason for including a nonce in the request
> is to enable a
> >client that doesn't have a very precise knowledge of
> time to still
> >be sure the response he got from the server was
> generated for this
> >specific request.
> >
> >While I do agree with Mark and think that the
> "right" way would be
> >to require the client to require the nonce in the
> response, in the
> >interests of moving ahead, I vote to accept Mike's compromise
> >proposal that a client MUST require the nonce in the response
> >unless it is accompanied by a nonceUnsupported extension in
> >the response and the client is willing to accept a
> response w/o
> >a nonce. This preserves the semantics for current clients and
> >still allows caching servers to supply responses to clients
> >who will take them.
> >
> >Regards,
> >Ambarish
>

RE: DISCUSS: MUST reject in OCSPv1

Hi Russ,
    This would *definitely* break compatibility with exisiting
software.

Currently, some folks put in some random bytes as the value of
the nonce extension, while others put in an OCTET STRING, whose value is
the random bytes.

The only check the clients do, is verify that the request contains
the same set of bytes.

Servers that include the nonce in the response include the bytes
they got in the request in the response.

The solution suggested by Mike would allow current servers and clients
to work as they do, and allow a way for smarter servers/clients to
work together where a server wanted to provide a response without the
nonce.

If we wanted to break compatibility, it would make more sense to use the
criticality bit in extensions (as suggested by others on the list).

Regards,
Ambarish

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
> [mailto:owner-ietf-pkix <at> mail.imc.org]On Behalf Of Russ Housley
> Sent: Tuesday, December 02, 2003 5:42 AM
> To: ietf-pkix <at> imc.org
> Subject: RE: DISCUSS: MUST reject in OCSPv1
>
>
>
> I am not very happy with the way that this discussion is going.  I am not
> convinced that a new extension is the best compromise.
>
> I have just reread the nonce-related portions of RFC 2560.  I
> must say, it
> is quite under specified.  It does not even provide a syntax for a
> nonce.  It really only provides the OID to identify the nonce
> extension and
> which extension location in which it is carried.
>
> It says:
>
>     The nonce cryptographically binds a request and a response to prevent
>     replay attacks. The nonce is included as one of the requestExtensions
>     in requests, while in responses it would be included as one of the
>     responseExtensions. In both the request and the response, the nonce
>     will be identified by the object identifier id-pkix-ocsp-nonce, while
>     the extnValue is the value of the nonce.
>
>     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
>
> Rather than defining a new extension, called nonceUnsupported,
> you have the
> opportunity to specify a syntax to go with this OID that does the same
> thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }
>
> Text that goes with the syntax definition ought to make it
> illegal for the
> request to use the NULL.  That is, it is only allowed in the response.
>
> I still prefer the "MUST reject" approach, but this seems like a cleaner
> solution than a new extension.
>
> Russ
>
>
> Ambarish wrote:
>
> >Hi Florian,
> >    The reason for including a nonce in the request is to enable a
> >client that doesn't have a very precise knowledge of time to still
> >be sure the response he got from the server was generated for this
> >specific request.
> >
> >While I do agree with Mark and think that the "right" way would be
> >to require the client to require the nonce in the response, in the
> >interests of moving ahead, I vote to accept Mike's compromise
> >proposal that a client MUST require the nonce in the response
> >unless it is accompanied by a nonceUnsupported extension in
> >the response and the client is willing to accept a response w/o
> >a nonce. This preserves the semantics for current clients and
> >still allows caching servers to supply responses to clients
> >who will take them.
> >
> >Regards,
> >Ambarish
>

RE: DISCUSS: MUST reject in OCSPv1

> -----Original Message-----
> From: Russ Housley
> Sent: Tuesday, December 02, 2003 6:42 AM
>
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }

Russ,

More precisely, based on the prior proposal, we have:

1. Cycle v1 at Proposed with the above
   amendment to nonce value syntax and
   the following semantics.

2. Clients that send a nonce:

   a. SHALL use the nonceValue CHOICE of
      OCSPNonce value syntax.

   b. MUST reject a response that fails
      to include the nonce extension
      (errors notwithstanding);

   c. Else, if such response includes a
      nonce extension with a value of
      "unsupported", clients MAY accept the
      response subject to the advice in the
      Security Considerations section of
      this document.

4. Conversely, if a server receives a nonced
   request but is unable to incorporate the
   nonce in its response, the server MUST
   include a nonce extension with the value
   "unsupported" for OCSPNonce.

So basically, it is pretty much the same semantics as previously
proposed, only using the "unsupported" CHOICE for OCSPNonce as
the caveat instead of an extension-based OID of "unsupported".

Is this what you had in mind?  Note that we still have a "MUST
reject" for plain responses.

Mike

OCSP in TLS handshake

Deacon, Alex wrote:
> 
> As for the nonceUnsupported proposal, it does have it merits. However
> I have to agree with Ryan by objecting to its standardization in v1
> for two reasons.  First, doing so will not allow for the "TLS 
> Extension" use case where OCSP responses are included in protocol 
> exchanges.

I'm not trying to be obtuse here (it actually takes very little effort), 
but I really need a patient explanation of why nonceUnsupported 
precludes the use of OCSP responses in the TLS handshake.

		M.

RE: DISCUSS: MUST reject in OCSPv1

But doesn't this ASN.1 additon make the interop issues with the existing
deployed client/server base even worse?  Its still not clear how we can
justify making such a large normative change to v1 at this point in the
process.  This spec has been at proposed for almost 4.5 years (!) now.

Alex

> -----Original Message-----
> From: Michael Myers [mailto:mmyers <at> fastq.com] 
> Sent: Tuesday, December 02, 2003 8:08 AM
> To: Russ Housley; ietf-pkix <at> imc.org
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> > -----Original Message-----
> > From: Russ Housley
> > Sent: Tuesday, December 02, 2003 6:42 AM
> >
> >
> >     OCSPNonce ::= CHOICE {
> >        nonceValue  OCTET STRING,
> >        unsupported  NULL }
> 
> Russ,
> 
> More precisely, based on the prior proposal, we have:
> 
> 1. Cycle v1 at Proposed with the above
>    amendment to nonce value syntax and
>    the following semantics.
> 
> 2. Clients that send a nonce:
> 
>    a. SHALL use the nonceValue CHOICE of
>       OCSPNonce value syntax.
> 
>    b. MUST reject a response that fails
>       to include the nonce extension
>       (errors notwithstanding);
> 
>    c. Else, if such response includes a
>       nonce extension with a value of
>       "unsupported", clients MAY accept the
>       response subject to the advice in the
>       Security Considerations section of
>       this document.
> 
> 4. Conversely, if a server receives a nonced
>    request but is unable to incorporate the
>    nonce in its response, the server MUST
>    include a nonce extension with the value
>    "unsupported" for OCSPNonce.
> 
> So basically, it is pretty much the same semantics as 
> previously proposed, only using the "unsupported" CHOICE for 
> OCSPNonce as the caveat instead of an extension-based OID of 
> "unsupported".
> 
> Is this what you had in mind?  Note that we still have a 
> "MUST reject" for plain responses.
> 
> Mike
>