On 19 December 2012 12:47, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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 <stephen.farr...@cs.tcd.ie> 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 :-) _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey