Re: [lamps] Proposed LAMPS Recharter

["Brockhaus, Hendrik" <[e-mail]>]

Thanks, that is even better
Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Russ Housley <[e-mail]>
> Gesendet: Freitag, 4. Oktober 2019 17:00
> An: Brockhaus, Hendrik (CT RDA CST SEA-DE)
> <[e-mail]>
> Cc: LAMPS WG <[e-mail]>
> Betreff: Re: [lamps] Proposed LAMPS Recharter
> 
> Hendrik:
> 
> You are correct.  I somehow dropped a sentence that was discussed on the
> list:
> 
> 	Necessary updates and clarifications to CMP will be specified in a
> separate document.
> 
> I suggest we stick with that wording ...
> 
> Russ
> 
> 
> > On Oct 4, 2019, at 1:49 AM, Brockhaus, Hendrik
> <[e-mail]> wrote:
> >
> > Should we also mention the CMP Updates in the re-charter.
> >
> > Proposal:
> > 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and
> it offers a vast range of certificate management options.  CMP is currently
> being used in many different industrial environments, but it needs to be
> tailored to the specific needs of some environments.  The LAMPS WG will
> provide some updates to CMP and develop a "lightweight" profile of CMP to
> more efficiently support of these environments and better facilitate
> interoperable implementation, while preserving cryptographic algorithm
> agility.
> >
> > Hendrik
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Spasm <[e-mail]> Im Auftrag von Russ Housley
> >> Gesendet: Donnerstag, 3. Oktober 2019 22:41
> >> An: LAMPS WG <[e-mail]>
> >> Betreff: [lamps] Proposed LAMPS Recharter
> >>
> >> Many of the work items in the current charter have reached the RFC
> >> Editor queue.  I believe that we can safely drop those topics.  That
> >> leaves three, including the CMP profile work that has already been
> discussed on the list.
> >>
> >> We do not have an active document for the short-lived X.509
> >> certificates work item that was directed to us by the SECDISPATCH
> process.
> >>
> >> Please review.  Is this ready to be sent to the IESG for approval?
> >>
> >> Russ
> >>
> >> = = = = = = = = =
> >>
> >> The PKIX and S/MIME Working Groups have been closed for some time.
> >> Some updates have been proposed to the X.509 certificate documents
> >> produced by the PKIX Working Group and the electronic mail security
> >> documents produced by the S/MIME Working Group.
> >>
> >> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
> >> Group is chartered to make updates where there is a known
> >> constituency interested in real deployment and there is at least one
> >> sufficiently well specified approach to the update so that the
> >> working group can sensibly evaluate whether to adopt a proposal.
> >>
> >> The LAMPS WG is now tackling these topics:
> >>
> >> 1. Specify the use of short-lived X.509 certificates for which no
> >> revocation information is made available by the Certification Authority.
> >> Short-lived certificates have a lifespan that is shorter than the
> >> time needed to detect, report, and distribute revocation information.
> >> As a result, revoking short-lived certificates is unnecessary and pointless.
> >>
> >> 2. Update the specification for the cryptographic protection of email
> >> headers
> >> -- both for signatures and encryption -- to improve the
> >> implementation situation with respect to privacy, security, usability
> >> and interoperability in cryptographically-protected electronic mail.
> >> Most current implementations of cryptographically-protected
> >> electronic mail protect only the body of the message, which leaves
> >> significant room for attacks against otherwise-protected messages.
> >>
> >> 3. The Certificate Management Protocol (CMP) is specified in RFC
> >> 4210, and it offers a vast range of certificate management options.
> >> CMP is currently being used in many different industrial
> >> environments, but it needs to be tailored to the specific needs of
> >> some environments.  The LAMPS WG will develop a "lightweight" profile
> >> of CMP to more efficiently support of these environments and better
> >> facilitate interoperable implementation, while preserving cryptographic
> algorithm agility.
> >>
> >> In addition, the LAMPS WG may investigate other updates to documents
> >> produced by the PKIX and S/MIME WG. The LAMPS WG may produce
> >> clarifications where needed, but the LAMPS WG shall not adopt
> >> anything beyond clarifications without rechartering.
> >>
> >>
> >> _______________________________________________
> >> Spasm mailing list
> >> [e-mail]
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >>
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
> >>
> brockhaus%40siemens.com%7C0b63866951bd40e98d8d08d7484222e1%7C38
> >>
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637057321200934913&am
> >>
> p;sdata=AHNsCOeT60Jrqo1TshfcFaS8a5l55SwdJp91pHAybno%3D&amp;reser
> >> ved=0
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com%7C8cbacca54cea4dc214fb08d748db7df0%7C38ae3bcd
> 95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637057979858599585&amp;sdata=OVidY
> Oe0j6%2
> > B9dDv3qGy7fIs85YFX6gdDaYFU3cbly2A%3D&amp;reserved=0