[lamps] Re: Call for adoption for draft-lamps-okubo-certdiscovery

[Russ Housley <[e-mail]>]

Michael:

https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-cert-discovery-00

https://datatracker.ietf.org/meeting/interim-2025-lamps-01/materials/slides-interim-2025-lamps-01-sessa-related-certificate-descriptor-00

https://datatracker.ietf.org/meeting/122/materials/slides-122-lamps-sessa-related-certificate-descriptor-01

Russ


> On Mar 22, 2025, at 4:54 AM, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
>> The authors have asked the LAMPS WG to adopt this I-D.  It defines a
>> method to discover a second X.509 certificate associated with a first
>> X.509 certificate.
> 
>> The Internet-Draft is here:
>> https://datatracker.ietf.org/doc/draft-lamps-okubo-certdiscovery/
> 
> I was confused by the I-D name.
> I read it. I'm surprised at how few references it has.
> Did we get a presentation at some point?  if so I forgot or missed it.
> 
> The process seems to be:
>    server: here's an invalid certificate
>    client: oh, yeah, I can't validated it, but I'll trust this SAI part anyway
>            <fetches new certificate>
>    client: validates new certificate, does rfc9125 work, maybe does
>            some DNS TLSA RR to see if new CA is acceptable.
> 
> Question 1: I assume that the backup certificate is completely validatable on
>         its own.  That we don't use the SAI to validate it, as if it were a
>         subcert (rfc9060)
> 
> Question 2: why didn't the server just use the second certificate, if the
>         first was invalid?  This goes to Use Case 2. "Operational Redundancy"
> 
> Question 3: Use case 1.  I thought that were going to have hybrid signatures
>         in our CA architecture.  That we don't need a parallel system, which
>         is how I'm reading Use case 1.
> 
> }  The third use case is where one certificate is used by the named
> }   subject for a particular cryptographic operation and a relying party
> }   wishes to obtain the public key of the named subject for a different
> }   cryptographic operation.  For example, the recipient of an email
> }   message which was signed using a key that is certified by a single-
> ]   use signing S/MIME certificate may wish to send an encrypted email to
> }   the sender.
> 
> So, I have your signing certificate, because I got a signed email from you.
> Now I want to send an email to you, and I need your encrypting certificate.
> This use case I buy.   Perhaps this request ought to be by email if offline.
> Maybe by LDAP if online.  Ideally by ohai for privacy reasons.
> 
> I don't object to adoption, but I'm skeptical about utility.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail] <mailto:[e-mail]>  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> --
> Michael Richardson <[e-mail] <mailto:[e-mail]>>, Sandelman Software Works
> -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> 
> 
> 
> J柆歠)鄸+-矕瑲'瓇娻N嫥叉靣笡z千u┺櫒ザ�)j丧y夒_