Re: [therightkey] review of draft-laurie-pki-sunlight-03

[Ben Laurie <[e-mail]>]

On 19 December 2012 12:47, Stephen Farrell <[e-mail]> wrote:
>
> Just the bits where there's something to say:
>
> On 12/19/2012 12:17 PM, Ben Laurie wrote:
>> On 17 December 2012 01:54, Stephen Farrell <[e-mail]> wrote:
>>
>>> - Where're the OIDs in 3.1 and 3.2 registered? They should be
>>> in the some registry I guess.
>>>
>>> - 3.1, shameless self-promotion - draft-farrell-decade-ni has
>>> a way to hash public keys:-) Yes, filling in the TODO is
>>> needed.
>>
>> Am I allowed to refer to I-Ds?
>
> You could. However, my I-D is gonna be stuck for a while
> since it has a normative dependency on http/1.1 drafts so
> unfortunately you're probably better to just copy the bit
> of text you need from there, if you want to use it. If
> you do that you could copy what you need and add an
> informative reference and it could all be fixed up later
> without slowing down your RFC.
>
> Or you could refer to DANE [rfc6698] assuming you hash
> the SPKI which both my draft and DANE do.

For a single sentence it seems simpler to just say it again!

>>> - intro, para 2: I'd avoid the word "prove" since mistakes can
>>> be made (e.g. a clock might be off)
>>
>> I am slightly at a loss for a better word here!
>
> s/prove/provide strong evidence /  maybe

OK.

>
>>> - 3.1, why "0..." for X509ChainEntry and "1.." for
>>> PrecertChainEntry? You probably ought say and that might need
>>> to change if you change the "same CA issued both EE cert and
>>> precert-signing-cert" rule.
>>
>> I can't parse this!
>
> Can't say I blame you, wonder who typed that silly comment;-)
>
> It was this bit that triggered the comment:
>
>     struct {
>            ASN.1Cert leaf_certificate;
>            ASN.1Cert certificate_chain<0..2^24-1>;
>        } X509ChainEntry;
>
>        struct {
>            ASN.1Cert tbs_certificate;
>            ASN.1Cert precertificate_chain<1..2^24-1>;
>        } PrecertChainEntry;
>
>
> The certificate_chain can be empty but the
> precertificate_chain cannot. That's right given the
> current spec, but maybe non-obvious.
>
> The 2nd part of the comment was that if you do need
> to change the precertificate_chain idea (if the
> issuing CA cannot create a precert issuer under itself
> e.g. because of a pathLenConstraint) then the
> PrecertChainEntry syntax might also have to change.
> I dunno if that'd be a real problem now, or only
> later, or is just theoretical but I'd say there
> will be CAs that can issue TLS server certs but
> that cannot issue a sub-ca cert for precertificates.

Well, in response to Rob's comment I'm going to have to change this anyway :-)