Subject: Re: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 12 Mar 2013 20:28:15 +0100

On Fri, 22 Feb 2013 16:15:13 +0100, Sean Turner <[email-masked]> wrote:

> Two questions, one comment, and one thing to note:
>
> Q1: Is text needed that restricts the number of requests that can go  
> with case ocsp to 1?  e.g.,:
>
>    The list of CertificateStatusRequestItem entries MUST be in
>    order of preference. When used with case ocsp, only one request
>    item is allowed.  When used with case ocsp_multi, more than one
>    request is allowed.

Theoretically, I can envision implementations that signal several
ResponderID lists, perhaps with different Extensions, where the server
picks RespondersIDs that it know, possibly with the default as a backup.
In that case you would want to have several of each type of request.

E.g.

     ocsp_multi(Resp1, ext1)
     ocsp(Resp1, ext1)
     ocsp_multi(Resp2, ext2)
     ocsp(Resp2, ext2)
     ocsp_multi()
     ocsp()

I agree it is unlikely that we will see such a scenario, but should we
explicitly forbid it? The reason for this extension is, after all, that
the original extension accidentally became too limited.

> Q2: Should there be an error if case ocsp is used with multiple requests  
> or when case ocsp_multi is used with only one request?

Given the above, only if we decide to restrict things.

Requiring errors for non-fatal problems could lead to implementation
differences. Checking for duplicates is also a possible programming issue;
it is implicitly required for the entire extension system, though.

> C1: CCITT was long ago renamed ITU.  How about we change:
> r/[CCITT.X680.2002]/[X680.2002]
> r/[CCITT.X690.2002]/[X690.2002]
>
> and use the same references from RFC 5246:
>
> [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
>         Information technology - Abstract Syntax Notation One
>         (ASN.1): Specification of basic notation.
>
> [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
>         Information technology - ASN.1 encoding Rules:
>         Specification of Basic Encoding Rules (BER), Canonical
>         Encoding Rules (CER) and Distinguished Encoding Rules
>         (DER).

The main thing about this is that the reference IDs are forced, at least  
in part, by the central bibliography index file, since I am only importing  
those via the XML2RFC file, and there is no entries with shorter reference  
names in the index, and I would rather avoid duplicating the entire index  
entry

> N1: OCSP is also about to be in last call so the references will likely  
> be updated to point to it at some point.

We'll handle that if/when it becomes relevant.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Sean Turner <[email-masked]>
Date: Tue, 12 Mar 2013 15:46:36 -0400

On 3/12/13 3:28 PM, Yngve N. Pettersen wrote:
>> Q2: Should there be an error if case ocsp is used with multiple
>> requests or when case ocsp_multi is used with only one request?
>

Okay so on Q1 and Q2 it looks like no.  If somebody cares, then they 
should say something on Friday otherwise I'll IETF LC it after the session.

> in part, by the central bibliography index file, since I am only
> importing those via the XML2RFC file, and there is no entries with
> shorter reference names in the index, and I would rather avoid
> duplicating the entire index entry

Okay, I'll get the RFC editor to fix this.

>> N1: OCSP is also about to be in last call so the references will
>> likely be updated to point to it at some point.
>

I plan to IETF LC this one at about the same time, but we can always fix 
the reference later.  This was more of a heads up.

spt

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 15 Mar 2013 04:20:21 +0000

Looks OK to me. 

On Mar 12, 2013, at 12:46 PM, Sean Turner <[email-masked]> wrote:

> Okay so on Q1 and Q2 it looks like no.  If somebody cares, then they should say something on Friday otherwise I'll IETF LC it after the session.
> 
> I plan to IETF LC this one at about the same time, but we can always fix the reference later.  This was more of a heads up.
> 
> spt
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls