Alvaro’s interpretation is indeed what I meant. My concern is with what works and what doesn’t work with the basic mechanism. How it will get used in practice is a related, but different, issue.
Thanks! Ben. > On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) <aret...@cisco.com> > wrote: > > [Explicitly adding Terry…] > > Tim: > > Hi! > > As I think you understand from the response below, there are two parts to > consider when deploying: what can be done, and what will be done. > Interpreting what Ben and Terry wrote…what I think they are asking is for you > to clarify in this document the considerations around mixing policies. For > example (to borrow from Terry), if a “TA has a particular OID and down the > tree an issued certificate has a different OID”, what are the > implications/problems/etc.? > > Note that this question is different from the document defining how things > may end up being deployed later (“whether this is an acceptable deployment > model”). The actual deployment discussions (as in, this is what we’re going > to do and when) should happen in sidrops. > > Thanks! > > Alvaro. > > > On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" > <sidr-boun...@ietf.org on behalf of t...@ripe.net> wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> This is probably just a matter of me being dense, but I'd like to understand >> what I am missing: >> Is it legal to mix certificate policies in a given cert path? The last >> paragraph of section 5 implies that you can, but doesn't say so explicitly. >> If >> you _can_ mix policies, what happens if you do? If I read the rules in >> 4.2.4.4. >> correctly (and it's likely that I am not), if you run into a cert in the >> chain >> that does not follow this profile, it's likely to give a null VRS-IP or >> VRS-AS >> value, which would seem to invalidate an certificate further down the chain >> that _does_ follow this policy? >> So, I guess it comes down to the following: If mixed policies are allowed, >> how >> does that work? If mixed policies are not allowed, there needs to be text >> that >> says that. It's quite possible such text exists (here or elsewhere), and I >> missed it. > > First of all it was my understanding that there was an agreement with the AD > that actual deployment should be discussed in sidrops. So this document > serves as a benchmark to describe the alternative algorithm. In my opinion a > mix is supported by this document, but the choice whether this is an > acceptable deployment model can be discussed later. > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
